C和C++混用

78 阅读 0 评论 52 点赞

我是靠谱客的博主能干鸵鸟，最近开发中收集的这篇文章主要介绍C和C++混用，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

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名字空间中释放出来，顺便更改命名风格，这都是偷换概念和分层设计的方法）。虽然我还没有参加工作，但是根据我的所见所闻，好的代码风格和低耦合度对于工程来讲是非常重要的，前者是软件工程师的必备技能，后者是系统设计师所追求的目标之一。