分类：
2009-03-31 20:25:56
| C和C＋＋混用是不是一个不好的习惯？在程序里面又用的STL，又用的C里面的函数。 |
C++不是保留这些函数，而是继承这些函数。
继承，就有更改。STL在继承这些函数的同时，把这些函数都归纳到了std名字空间中，虽然只是直接调用，但是毕竟有概念上的区别：您正在使用STL的std空间。例如你在你的代码前面加上using namespace std;之后，你代码中的abs调用就从原来的::abs转换为了std::abs。
STL和C的标准库有血缘关系，因此许多C标准库中的函数都可以和STL库在代码级（而不是二进制级）无缝兼容（这种兼容性是STL提供的），换作别的库情况就大不相同了，例如MFC、VCL、STL/C标准库，他们之间无法兼容，混用会导致代码的混乱、效率下降、安全性打折扣。起码他们的代码风格绝然不同，概念也千差万别。
另外，VCL和STL也有血缘关系，VCL的底层使用了STL容器类，但是仔细研究发现VCL在使用STL之前都对STL的命名风格进行了转换，把全小写的UNIX/C风格转换为了首写字母大写的Borland风格，这样做就是力求代码不会混乱。如果你把各种库都糅合起来使用，既有UNIX/C的全小写+下划线风格，也有Borland的首写字母大写风格，再加上Microsoft的匈牙利风格，那么你的代码看起来一定像一盘糟糕的涂鸦大杂烩，再次，概念上能否融合那是深层次的问题。
| Yes， C和C++混用的确是natural，毕竟绝大多数C++学习者都从C学起，C++兼容C就是为了降低学习门槛。但是C和C++混用却不一定是necessary。 我们把C和C++归为一类，通常写作C/C++，那是因为从语言角度讲C的问题就是C++的问题，但是反过来就不成立，因此具体到某个工程的时候，你在开工之前就必须决定到底使用C还是C++，或者说到底是面向过程还是面向对象。当然，上面两种说法都不正确，因为C并不一定就是面向过程，C++也并不一定就是面向对象。不过面向过程的设计已经不适应潮流了，因此准确的提问应该是：到底使用C风格（以函数为元素）的面向对象还是C++风格（以类为元素）的面向对象。 在系统设计阶段就必须确定设计风格，因为这很重要，关系到代码的样式、兼容性、可移植性，风格的选择依据就是你手头的库，看你手头上能够使用的库有哪些，以哪一个库为基准，以及开发进度要求，这些因素必须平衡考虑，不能顾此失彼。 如果只是开发一个小程序（就是类似那种用C++Builder或者Dephi可视化功能再加上一些控件组装出来的程序），那么把各个能够使用的库糅合起来就可以了。 如果是一个大的需要持久维护的工程，就必须考虑库与库之间的兼容性、效率、耦合度。所谓兼容性就是这个库的概念（包括你所知道的任何能够保存的量）能否传递给另外一个库直接使用；所谓效率，就是不能直接传递的概念是必须转换的，这个转换的花费是高还是低；所谓耦合度，就是当需求按照预期变化的时候（如果系统设计师没有考虑这一点的话，那么他应该下岗了）你能否轻松的转换接口或者库（接口是外部的，库是内部的）。 很显然，如果你直接把所有能用的库糅合起来的话，虽然兼容性和效率在绝大多数情况下符合要求，但是耦合度这一关就很难过了。当你发现某个库不能满足需求了，必须转换到另外一个库的时候，你就追悔莫及了。因此直接耦合肯定是不行的，必须转换接口和概念（接口是外部的，概念是内部的），类似于《Design Patterns》里面介绍的Adapter模式，许多读过这本书的人一定对基于接口的Adapter影响深刻，但似乎很少有人注意到包括Adapter模式在内的其他模式都可以适用于范型，而范型是内部概念转换的最好方法。 所以说，你在一个工程里面使用多个风格迥异的库完全可行，但是最好不要直接使用，要学会偷换概念或者通过分层设计以降低对外来代码（就是说不是你写的代码）的依赖性，同时还可以保证自己的代码风格一致。（STL把C标准库的函数inline到std名字空间下，VCL则把STL中的容器从std名字空间中释放出来，顺便更改命名风格，这都是偷换概念和分层设计的方法）。虽然我还没有参加工作，但是根据我的所见所闻，好的代码风格和低耦合度对于工程来讲是非常重要的，前者是软件工程师的必备技能，后者是系统设计师所追求的目标之一。 |
