在c++项目中使用opensource library

前两天,cleveland的开发组发来一封群信,意思是说公司的法律顾问已经研究通过了,允许在公司产品中使用boost库。

对于这件事当然是高兴加上赞成。不过也有一些个人看法。

boost号称是c++标准库的预备役,因为里面不少library的质量相当高,比如正则表达式和智能指针,还有线程库socket库等等。不过强大的武器需要操作它的人更加有能力,也就是说,如果不十分熟悉这些库的优点缺点局限性,到时候会出大问题的。

我就在工作中遇到过很搞笑的设计。一个读取配置controllogix gateway信息的dll,将底层通讯部分剥离到另一个dll中,这种设计本身没有大问题,关键是使用了COM的连接点connection point技术,但是数据却使用内存指针直接传递。我只能对设计这种方案的人举双手赞成,实在是高,真没有想到COM技术与内存直接共享都能放到一起。

当初的设计方案毫无疑问是只能启动一个dialog,这时候负责界面的dll和负责通讯的dll都活的好好的,可是总有不如意的地方,有的用户发现竟然能同时启动多个对话框,还认为这是应该的,于是我的噩梦就来了,修改这个设计方案费了我好大的劲,其实可以做的很简单,使用一个线程去进行通讯工作,去掉所有不必要的COM设计,保证稳定。

从DDE到COM技术,到现在的DotNET Platform,我都无法信任它们,能不用就不用。最根本的原因是这些库或框架的代码不开放,出现问题以后,在COM与调用代码之间就形成了无法跨越的障碍。到底是COM的局限?还是我们代码写的有问题?无法进一步跟踪下去,只能想方设法的查找MSDN或者修改COM相关的代码。我就遇到过COM延迟二十几秒的恶心问题,频繁的调用接口的初始化就会导致COM初始化的失败,大约要停止20多秒。这应该是类似于内存碎片这样的问题,就是不能频繁调用new/delete申请释放小块内存,具体原因应该是操作系统自身的毛病,可是不能修改COM方面的代码,只能想法修改自己的。

有人看过Windows2000泄漏出来的代码,里面大多数都是用c写就。也就是说,没有c++的继承多态,当然更不可能有什么COM了。主要的原因应该不难猜测,C++与COM不可控制的东西太多了,而对于操作系统来说,不可控制因素的存在是致命的。当然,对于应用软件来说,这些就不太算是问题,不过用的不熟练的,还是不如不用。(我也见过用的相当熟练的设计方案,简直是帅呆了,自叹不如啊,比如custom moniker,没听说谁用过,潘爱民的书里介绍的也是简单,但是我们一个组件里就大量的使用了这些高级的COM概念,而且设计相当稳定)

回到boost这个话题,如果大连campus有C++标准库的大牛,使用boost肯定会提高代码质量,提高开发水平。但是现状是大家对STL用的都不熟,如果加上Boost,那只能是另一个噩梦的开始。另外,boost毕竟不是标准,稳定性和向后兼容性要差一些,这对于商业软件来说,都是值得仔细考虑的地方。

我的建议是用熟STL,在熟练的基础上再去尝试Loki或者Boost,但是不要将其引入legacy project,可以把它用在一些单独组件中,将其不可预知的风险降低到最小。

这也只是想想而已,就如郭德纲说的那样,谁认识我呀。

《在c++项目中使用opensource library》有3个想法

  1. 这个COM是指微软的COM么,那可能不太好找。我只知道有一个Linux下的.NET实现,也就是MONO啦。

    因为现在可能微软都是在维护而不更新COM了,开源社区不太会有人跟进这个领域。

  2. COM的竞争对手有CORBA,ICE,ACE,XPCOM等等(我孤陋寡闻,只知道几个)。

    CORBA在LINUX或者BSD家族操作系统下用的相当广泛了,嘿嘿,就是GNOME啦。XPCOM是Mozilla开源家族的作品。ACE是跨平台网络服务代理xxx。应该说,开源的人不会去用COM啦,因为可选择的很多,何必跟微软去搞。而且还可能有智慧财产权的问题吧。

发表评论