CSDN博客

img xiaohyy

模块复用——c++类、dll和com

发表于2003/12/29 11:03:00  1839人阅读

    这篇文章只是对c++、dll和com的泛泛而谈,更为详细的内容请参考《com本质论》,这篇文章也算是《com本质论》第一章的读书笔记或总结。如有不对之处,希望大家批评指正。

在windows下使用c++编写代码的人代码复用的常用方式大概就是c++类、dll和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的用处还很多。Com技术也很复杂,我也不想多说 了,一是因为我懒,二是因为我水平还很菜,《com本质论》是一本好书。学com一定要看。

    最后,想谈谈目前的软件开发环境。由于.net的推出,很多人在问现在学习com还是否值得。看看目前的软件,ie,office,msn包括.net的核心,哪个不是用com搭建起来的,而且我们学习com,关键是它的设计思想,知其然而知其所以然,了解了其背后的设计动机,用com还是用dll都是一样的了,如果只是用用,不学也罢. 。dll只是com的一种发布形式而已。即使在其他平台,这种思想也是很有用的,在com中体现的是OO的思想——接口和实现的分离、开-闭原则、针对接口编程,甚至强迫你使用某些设计模式。我认为,这就是学习com的价值。。而且,研究atl的源码中对com的实现,也能学到一些实用技术和设计模式。而这些东西是永远不会过时的。。技术是在不断演化的,但新技术也是旧技术积累产生的。Wtl之父也建议在学习.net前学学com。实际上,在window平台上,com永远有它的一席之地。。。。

0 0

相关博文

我的热门文章

img
取 消
img