ftofficer|张聪的blog

应该是公司花了不少钱请来的，虽然据他说他和趋势一直保持着良好的关系。

今天第一天，后面还有两天，题目关于Design Patterns。第一天总体感觉不错，jjhou确实是一个文字的高手，也可能是看得多了，翻得多了，写得多了，讲得多了也就自然成了高手。旧的东西从新的人口中讲出来，往往可以有更多的认识。

今天主要讲的是一些比较简单的OO概念和几个简单的模式，讲模式从Template Method开始，引出重用的基石：延迟实现；然后从其不足引出Strategy，然后解释OO当中的delegation。这个门入的非常cool。我们也在做Design Patterns的讨论班，从Factory模式开始，结果发现非常难于入门——不太熟悉的人都在问：为什么我们要用Factory来创建对象？今天发现，结构型模式，尤其是Template Method确实是一个不错的切入点。而且jjhou也说，Factory一定程度上也是由于Template Method产生的——当算法骨架当中需要创建object的时候。

然后是Adapter。本来我一直认为Adapter非常的简单，因而从来没有深入的考虑过Adapter更深层的东西。今天jjhou的例子却让我打开了一个新看待Adapter的视角：STL的functor adapter（事后查了一下《STL源码剖析》，发现其中有讲）。其实interface不一定是纯虚基类，std::unary_function也是一种interface，考虑template meta programming，当中的typedef也是一种interface！cool。原来adapter真的无处不在。

吃过晚饭一直在讲Reference Counting，传说中的来自于More Effective C++。这本书在大二的时候浏览过一番，后来就再也没有重读（那个时候还不知道什么是Design Patterns）。现在回头再去读一下，发现确实有一些不同的收获。一个Reference Counting的东西讲了这么久是因为例子。例子应该还是来自于他的《STL源码剖析》，源于SGI STL（古老的用于写书的那个版本）当中的string实现，中间穿插有copy on write。整个讲述的过程当中思路非常好，如果思路跟的上（其实以他讲的速度基本上都可以跟得上），听起来的确有趣，和他的书一个风格，从故事开头娓娓道来，深入浅出。不过我一直在考虑这个东西用在string上面的意义。Reference Counting用在string上面的最大问题在于非透明性——尤其对于遗留下来的代码的复用：试想一个用C实现的程序需要一个char*指针，如果这个时候传入了一个用Reference Counting实现的string.c_str()得到的东西，那么十有八九会出现问题。遗留下来的C程序并不知道这个东西是不是被share了，或者他的Reference Counting是多少。有人说“你不用c代码不就行了”，没错，非常好，但是在大型项目当中几乎做不到：大型项目有很多遗留代码和无法控制的第三方库，你可以在重写和复用之间权衡，但是一旦选择了复用，想要不出问题，概率大概和南京一整天不出现车祸的几率差不多（大概<0.1%）。所以VC8的std::string已经彻底抛弃掉了Reference Counting，大概也就是因为Windows平台上如此多的遗留程序和软件造成的。

但是string的Reference Counting的问题不足以掩盖Reference Counting的价值。但是一个好的Reference Counting的代码太难写了，尤其是要保证线程安全的时候（比如CComObjectRoot和CComMultiThreadedModel）。感觉还是非侵入式的Reference Counting比较安全一点，例如shared_ptr，这个应该明天会讲。

仔细想想为什么Reference Counting + Copy on Write这么难搞定，直接原因是因为现实和理想之间的差距：因为c风格的字符串处理函数无处不在——虽然guru们建议我们不要用它们，但是那之前的历史更长。而c风格的字符串处理函数有一个假设，即字符串的二进制布局：以单字节零结尾的连续内存空间。但是string没有这个假设。至于这种对于二进制布局的放弃，确实增加了string的灵活性，但同时也增加了互操作性的难度。我感觉在现在的环境当中来看，在C++程序员对于“用const引用替换传值调用”已成为一种思维定势，并且编译器有了更强的优化能力的情况下，在string上面使用Reference Counting真的是弊大于利。Reference Counting解决的是减少复制string对象的内存分配开销，而一旦使用了Reference Counting，为了保持string的行为，修改两个共享存储的string对象当中的任何一个都必须使用Copy-on-Write。但是，当C++程序员复制一个string对象的时候，他的目的在绝大多数时候都是为了修改它（我相信对于大多数有经验的C++程序员来说，这个命题基本成立），如果这个假设成立的话，Reference Counting的作用其实并不太大。不过仍然存在着其他的可能性，例如作为类成员的string object。不过我认为这种东西不应该会是性能的瓶颈：如果人们需要频繁的拷贝一个具有string成员变量的类实例，这种设计往往就有问题，有经验的C++程序员应该会避免的。剩下的能够从string的Reference Counting当中得利的，也就是很少的一部分case了。这种时候去寻找一个用Reference Counting实现的专用版本的string，看起来似乎更加合理。

在我看来，C++从一开始就放弃对二进制和线程模型的标准化也许是一个错误（虽然这样确实让C++可以在更多的平台上发挥作用）。因为没有二进制和线程模型，C++才不得不在编译期做文章，于是才有了模板元编程和很多的编译期优化手段。但是对于强调运行期的可配制性的产品，编译期的手段很难有用武之地。这种环境当中，更加动态的，可以在运行期变化的方案更受欢迎。这么来看，介于编译型语言和脚本语言之间的方案会很有前途，比如.NET的IL+JIT。