CString的部分实现剖析

一、CString初探：

   在CString的实现中，其最基础的类结构如下：

 

   CString其实只有一个数据成员m_pszData，这个成员指向了字符串的首地址。但在MFC的具体实现中， m_pszData 指向的其实是 CStringData 后面的一块数据的首地址。比如执行

CString strHello = _T("hello");

   这样一条语句之后，m_pszData的指向其实是下面这个样子：

 

                 m_pszData

                    ↓

    +---------------+--+--+--+--+--+---+

    |  CStringData  | h  |  e |   l |  l |   o |  \0 |

    +---------------+--+--+--+--+--+---+

 

   我们知道，CStringData里面的信息如下：

   IAtlStringMgr* pStringMgr;       --> 执行Allocate、Reallocate、Free等操作；重要的一点，提供GetNilString方法的实现（下文会讲到）；   int            nDataLength;      --> 字符串的实际长度（通过SetLength等函数可操作这个大小）；   int            nAllocLength;     --> 实际分配的空间大小（除非重新分配，否则这个大小不可变）；   int            nRefs;            --> 明显为了支持 CopyOnWrite 机制，为引用计数

   我们可以看出，CStringData里面有字符串的长度信息，但在CAfxStringMgr::Allocate的时候确实又为 '\0' 分配了空间。

 

   也就是说，每当字符串发生更改或者触发了 CopyOnWrite 的机制时，就会调用 CAfxStringMgr 的 Allocate/Reallocate 函数进行分配空间，分配的大小为：

      (nChars + 1) * nCharSize + sizeof(CStringData)

 

二、CStringData和m_pszData的关联

   当执行CString的默认构造函数时，会调用前面我们提到的CAfxStringMgr::GetNilString返回一个CStringData的指针，这个指针指向全局的一个CNilStringData。CNilStringData如下：

 

   CNilStringData派生自CStringData，额外拥有一个 achNil 的数组成员，这个数组初始化为空字符串。通过这个achNil，保证了一个经过调用默认构造函数初始化的CString，其指向的真正的字符串是一个空串。CSimpleStringT的构造函数如下：

 

注意，这里为什么是一个长度为2的数组？原来，有时候我们需要两个'\0'结尾的字符串——比如用GetOpenFileName打开一个文件的时候，需要在OPENFILENAME的lpstrFilter填入一个两个'\0'结尾的字符串，这样，万一我们用一个默认的CString空串来传值的时候，不会造成Crash。

   重要的是接下来的Attach操作，通过Attach操作，将这个CStringData*与CSimpleStringT::m_pszData执行了关联：

 

   pData->data() 具体做了哪些操作呢？

   

     可以看出，data() 是CStringData类里的一个成员函数，它返回this指针加1之后的一个指针。我们知道，对于一个类型为T*的指针，对它取偏移，得到的实际地址是：ptr + sizeof(T) * offset。所以，针对一个CStringData*的指针作偏移，得到的地址是紧挨在CStringData之后的那块数据块的地址。

   这样，就顺理成章的将字符串的真正的指针m_pszData和描述字符串信息的CStringData关联了起来。那么，我们也可以很容易的通过m_pszData反推出CStringData的指针，CSimpleStringT::GetData这个成员方法就提供了这么一个操作：

 

   先把 m_pszData 强转为 CStringData* 的类型，再在这个基础上做 -1 的偏移，得到的就是真正的CStringData的地址。

 

三、CopyOnWrite机制的触发

   CopyOnWrite——写时复制机制，这个机制也算非常常见了。我第一次接触这个机制，是DLL的写时复制，当要手动Hook一个DLL中的API时，会在API开头手动写入跳转汇编，这时候，系统会复制一份DLL镜像给我们，不会影响到加载该DLL的其他进程。

 

   CopyOnWrite，说白了：就是大家先共享一份数据，可以进行共享只读操作，事情顺利进行；突然有个家伙想修改这份数据里的某一个地方，如果发现这块数据是由多个人共享的，那好，你自己把这份数据复制一份，然后把共享的引用计数减一，然后你自己去玩吧。

 

   CString也是提供了这样一个CopyOnWrite机制的，其中，CSimpleStringT::Fork函数就提供了这样一个操作，具体分为下面几步：

      1> 它根据传入的一个长度分配一段新的空间；—— Allocate(nLength, …)

      2> 把旧数据拷贝到新的空间里面；—— CopyChars(…)

      3> 旧数据块的引用技术减1； —— pOldData->Release()

        4> 把m_pszData和新的数据块关联起来。—— Attach(pNewData)

 

   那么，什么时候会触发CopyOnWrite机制呢？一般来说，对CString进行写操作的所有方法，都会触发该机制，Write操作都会进行，但只有该字符串的数据块被共享的时候，或者旧的CStringData::nAllocLength不足以存放新的字符串的时候，才会执行Copy操作。这些对CString进行写操作的方法，大家通过使用经验和肉眼，很容易就可以分辨出来。

 

四、 operator LPCTSTR及GetBuffer的故事

  1> operator LPCTSTR：

   OK，有些API接受的入参可能不是CString，而是一个char*或者wchar_t*的字符串指针，这时候，我们往往会用到 LPCTSTR 的一个隐式转换函数——operator LPCTSTR，如你所想，它干了你想让它干的，就是返回m_pszData：

  

   呃，PCXSTR，说好的LPCTSTR呢？原来，对wchar_t类型的字符串，PCXSTR的定义是这样的，还是LPCWSTR，这里夹杂的大写“C”，保留了const属性：

 

   这里我们要注意了：当我们执行 (LPCTSTR)str 这样一个强转操作，就会调用到 operator PCXSTR 这个转换函数，返回的是带const属性的字符串指针，所以，我们不应该对这个指针做任何的写操作。比如：

   CString str1 = _T("hello");   CString str2 = str1;                                 // 这时候 str1 和 str2 共享字符串 "hello" 的数据块     LPCTSTR pcszAddr = (LPCTSTR)str1;   LPTSTR  pszEvil  = const_cast<LPTSTR>(pcszAddr);     // 我们邪恶一下   pszEvil[0] = _T('H');                                // 强制改一下，这时候 str1 和 str2 都变成了 "Hello" 了！

 

   所以，当我们要对字符串只读的时候，应该使用这个隐式转换符，或者调用CSimpleStringT::GetString方法，这两个操作完全等价：

 

   2> GetBuffer：

   比起GetString或者operator PCXSTR，GetBuffer函数就有趣多了。

 

   这里我们注意到，返回的是PXSTR而不是PXCSTR，也就是说，GetBuffer返回的字符串，是不带const属性的，我们可以进行写操作——那么，为了不影响其他共享的字符串，这里触发了CopyOnWrite机制！——当然，如果pData->IsShared返回FALSE的话，说明没有共享，是不会Copy的。我们再尝试邪恶一把：

   CString str1 = _T("hello");   CString str2 = str1;                                  // 这时候 str1 和 str2 共享字符串 "hello" 的数据块     LPTSTR pszEvil = str1.GetBuffer();   pszEvil[0] = _T('H');                                // 强制改一下，这时候 str1 变成了 "Hello"，str2 依然为 "hello"！

   可以看出，我们通过GetBuffer得到的字符串指针，是可以写的，不会影响到其他字符串。很遗憾，这里，我们没有邪恶成功。

 

  3> GetBuffer的重载版本：

   What！还有重载版本？对的，CString还有一个重载了的GetBuffer函数，这个重载版本接收一个int的长度作为入参：

   继续调用了PrePareWrite，继续往下跟：

   发现新需求的长度比已经分配的小，或者字符串数据块被共享，就调用PrepareWrite2，否则，直接返回m_pszData，我们继续往下跟：

   这里，第二个if分支，发现数据被共享，直接执行Fork进行Copy操作，接下来的elseif分支，如果没被共享，但已分配的最大长度小于用户请求的长度，则进行扩容，然后调用Reallocate进行重新分配。

 

   Reallocate的执行，大家可以参见源代码，这里就不贴了，其实现，大概可以想到个八九分吧。Fork和Reallocate最后都执行了Attach操作，将新数据块和m_pszData关联起来。

 

五、“到底要不要ReleaseBuffer，This is a Question!”

   那么，大家的疑问一直纠结在这里，GetBuffer之后，到底要不要ReleaseBuffer？

  

  1> ReleaseBuffer干了什么？

   我们要判断一个函数该不该调用的时候，如果一直找不到想要的结果，参考源代码，不失为一个好选择：

 

   ReleaseBuffer如果你不传任何参数进去，它会取字符串的真实长度（这里通过调用wcslen获取），然后进行SetLength操作。但如果你传了一个长度，它会直接用这个长度进行SetLength操作。

 

   SetLength干了什么？只是把新的长度赋到CStringData里面，并且把字符串按新长度，在对应的位置塞入 '\0'：

 

“哦，哦，怎么感觉满世界都是坑呐！”——你这样埋怨道！我们发现，ReleaseBuffer干了一件与它的名字完全不符的一件事，你这是闹哪样？结合ReleaseBuffer做的操作，我们完全有理由相信：UpdateBuffer这个函数名，更适合这么一个操作！

 

  2> 什么情况下需要调用ReleaseBuffer：

   那么什么情况下需要调用ReleaseBuffer呢？我们看到，GetBuffer返回的是可写的指针，也就是说，我们得到这个字符串指针的时候，如果发生了一些写操作，那么，CString是不知道我们干了什么的，因为我们没通过CString提供的接口去操作。所以，我们需要ReleaseBuffer（UpdateBuffer什么时候能被扶正？）来把字符串的新长度更新到CString里面——具体点，更新到CStringData里面，因为我们调用CString::GetLength的时候，需要用到这个长度：

 

   举个具体的例子：

   CString str = _T("Hello World!");   LPSTR pszAddr = str.GetBuffer();                // pszAddr 为 "Hello World!"   int nStrLength = str.GetLength();               // nStrLength 为12    pszAddr[6] = 0;                                 // pszAddr 变成了 "Hello"，但str这个对象并不知道，它的m_pszData已经不是从前的那个它了   int nStrAfterChangeLength = str.GetLength();    // str依然相信，nStrAfterChangeLength 依然是 12    str.ReleaseBuffer();                            // 我们让第三方悄悄告诉str，你的m_pszData已经变了，你最好重新审视一下它   int nStrAfterUpdateLength = str.GetLength();    // nStrAfterUpdateLength 变成了 5，虽然变短了，但str不得不接受这个现实