博客

前两天，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，可以把它用在一些单独组件中，将其不可预知的风险降低到最小。

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