ATL、MFC、WTL CString 的今生前世

转载:

http://www.cnblogs.com/tekkaman/archive/2011/04/20/2022650.html

上文分析了ATL、MFC CString的设计和实现，我们不禁会疑问，为什么ATL和MFC的CString头文件要搅在一起？

上文的分析有些杂乱，我们通过一张图来更加清晰的观察，如下：

上图中，用圈圈住的头文件表示ATL头文件，没被圈的代表MFC头文件。另外，在头文件旁边字符，表示各个头文件中实现的类。

现在让我们仔细观看，整个貌似平衡的设计中，其实有着很多的不平衡。我想问：

1、为什么MFC头文件cstringt.h要包含atl头文件atlsimpstr.h？为什么ATL头文件要包含cstringt.h？ATL搞ATL的，MFC搞MFC的，各不相干，起不更好？

2、ChTraitOS 放在 atlstr.h 中，而 ChTraitCRT 放在 cstringt.h中，他俩功能是类似的，逻辑上是相对的，为神马在文件层次上却不对齐，要如此的别扭？

话说中国人看待问题的时候，往往把某一大类看作一蹴而就的完美的整体。譬如Tencent很赚钱，很大，产品推出快，人们就认为Tencent内部有着良好的组织架构。这里我要告诉大家的是，任何大规模的东西，都是一点一滴积累起来的。ATL也是，MFC也是。这两个东西不是一个月、两个月的开发就成了现在的样子的，他们都是逐步叠加，逐步改进才成了今天这个强大的库的。扯了这些，是要告诉大家，要以变化、积累、动态来看待和分析事物的衍生。

好了，现在我们来看为什么微软会搞出这么别扭的结构。

话说，某一天ATL开发小组发现老是操作char，太低效，STL的string也不是很好用，于是乎，他们做了一个为ATL服务的简单的字符串类，名字叫 CSimpleStringT，通过typedef，定义成了 CSimpleString。

后天某一天，MFC的人也发现char和string超不好用，他们发现公司的ATL小组已经做了一个成熟CSimpleString类，于是MFC小组拿来直接使用。在使用中，MFC小组的人发现CSimpleString做的太简单了，有很多的功能，它都不提供，另外，类函数设计的也不好用。于是MFC小组的成员决定扩展CSimpleString，他们将扩展的代码写进cstringt.h中，另外抽离出对外的接口头文件afxstr.h，将定义放在了这。（到这里，我们发现了上面提到问题的发生点，MFC的头文件继承了ATL头文件）。

又到后来，MFC小组的某个成员（主程级）转到了ATL小组，来到ATL小组后，他发现，平日用惯了CString，现在要用CSimpleString真TM憋屈，于是他建议在ATL中自封装一个CStrnig。ATL小组发现，继然MFC的CString已经做得这么成熟稳定且好用了，自己没必要再另起炉灶，另外，他们发现cstringt.h是独立于MFC其它文件的，虽然属于MFC小组（MFC小组所写），但是引用的却都是atl的头文件，因此，引用cstringt.h不会融入MFC其它旁大的文件，因此可行。所以综合以上考虑，ATL小组直接继承于cstringt头文件，派生了自己的CString，放在了atlstr.h中。（注意，连名字取得都和afxstr.h相对应，到这里，我们又看到，ATL头文件继承了MFC头文件）。

就这样，诞生了两份CSring。日子很平淡的一天一天过去，直到有一天，有个项目要混用ATL和MFC，他们发现，有两份CString，编译不过！因为ATL的CString毕竟只是模仿MFC，于是ATL让路，加上了宏定义 #ifndef _AFX ，意即，在没有使用MFC时，ATL才定义CString。

ATL 和 MFC CString的故事讲完了，相信大家对CString相关文件目前结构的来龙去脉应该很清楚了。但是WTL呢？为什么WTL也要定义一个CString？话说WTL编写过程中，WTL组的后生小辈们看了ATL的CString代码，他们觉得咋这CString搞得咋这么复杂呢？看得头都大了，于是他们设计了一个四两拨千斤的CString，不继承任何东西，不依赖任何东西，就是一个简简单单的类。在初期，他们工作得很好，但是到后期，他们发现，如果两个人的代码用的是不同的CString的话，那么将代码合并的时候，编译不过，和之前遇到的问题一样，会产生两个CString，于是WTL不得不加了另外一个宏 _WTL_NO_CSTRING 来禁止WTL CString的编译。