C++,DLL,COM,COM+概述[转]

一、C++代码重用的缺陷
    以前的C++开发人员复用代码的方式大概就是获得一套.h和.cpp文件，然后把这些文件加入到自己的工程中编译、连接，最后生成exe文件。这种代码级的复用方式存以下的问题

1、C++程序员通常根据自己的需要修改别人提供的代码。开发者要使用代码，通常会根据源代码来理解代码的意图。更为老火的是，还要理解代码提供者的思路和编码风格

2、C++代码级复用导致了硬盘和内存空间的浪费
    假如机器上有n个软件使用了类CA，在每个软件的存储空间中都会有class CA的一份编译生成的代码，在这n个软件同时执行时，会占用n×sizeof(CA)大小的内存空间

3、软件一经发布，除非重新编译整个软件，否则无法修改
    假如发现了类CA存在一个bug，要修改CA的实现来修复这个bug，那么就只有重新编译整个软件。软件根本就不具备2进制的模块化特性。

二、如何解决以上问题————dll的引入
    在window中，一个很好的技术就是动态链接库（dll），有了dll技术，客户可共享该dll的代码，这样在用户机器上无论有多少个软件使用该dll，都会只有一份该dll的拷贝。而dll提供给开发者的也只是.h文件，隐藏了代码的实现细节。

三、dll复用存在的问题
1、编译器、连接器的不兼容问题
    为了支持重载，C++编译器任意修改函数名（名字改编，感兴趣的可参考《深入探索C++对象模型第4章——function语意学》），而且每个C++编译器修改函数名的方法通常都不相同。这个问题的一个解决方案是将函数声明extern “C”链接指示符,这样做的一个缺陷是：不能用extern “C”声明成员函数。另一个解决方案是修改DEF文件，这样可保证所有的编译器导出相同的函数名，可保证dll在链接时的兼容。但这还不能保证2进制结构的兼容性，由于C++标准并未规定程序运行时的状态，每个编译器可能有自己的一套处理方式，比如在做异常处理时，一个编译器抛出的异常，在另一个编译器中可能不能扑获到

2、dll致命的弱点——版本冲突问题
    dll的版本问题是臭名昭著的。解决版本冲突问题的经典方法是重命名dll文件名（这也是mfc的解决方案，mfc42d….mfc42ud等）。

四、祭出法宝，面向对象的原则——接口和实现的分离
    dll版本问题的关键在于C++的编译模型和对象之间的紧密耦合关系，C++编译模型要求客户需要了解对象的内存布局，以便为对象分配内存。该问题的根本解决之道是分离接口和实现。把实现封装在dll的内部，客户通过接口来访问实现。这样，在客户代码中不会包含复用模块的实现部分。

五、com的解决方案
    com是严格分离接口和实现的，客户只能通过接口来访问组件的实现。保证了不把任何实现细节暴露给客户。在客户使用组件分配内存时，也只有com接口中的 vptr指针。Com使用接口继承的方式分离接口和实现。而大多数编译器对vptr和vtbl生成的内存布局是一致的。这样就解决了编译器之间的不兼容关系。

com+是在win2k下提出的，在组件服务中配置com组件，该com组件就成了com+，也是windows DNA 的基础com+ = com + MTS + MSMQ

 

来自

http://hi.baidu.com/%C1%AA%CC%EC%BA%CF%B5%D8/blog/item/3a84c0eea17eda3aacafd5ca.html