我们有一个用 C++ (MFC) 编写的多线程桌面应用程序。目前开发人员使用 CString 或 std::string，可能取决于他们的心情。所以我们想选择一个实现（可能不是这两个）。
MFC 的 CString 基于写时复制 (COW) 习惯用法，有些人会声称这在多线程环境中是不可接受的（可能参考本文 http://www.gotw.ca/publications/optimizations.htm）。我不相信这样的说法，因为原子计数器似乎相当快，而且这种开销在某种程度上可以通过减少内存重新分配来补偿。
我了解到 std::string 实现取决于编译器 - 它在 MSVC 中不是 COW，但在 gcc 中是或曾经是。据我了解，新的 C++0x 标准将通过要求非 COW 实现来解决此问题，并解决一些其他问题，例如连续缓冲区要求。所以实际上 std::string 目前看起来没有很好的定义......
一个我不喜欢 std::string 的简单例子：如果没有过多的重新分配，就无法从函数返回字符串（如果按值返回，则复制构造函数，并且无法访问内部缓冲区来优化它，因此“返回通过引用”例如std::string& Result没有帮助）。我可以使用 CString 通过按值返回（由于 COW 而无需复制）或按引用传递并直接访问缓冲区来完成此操作。同样，C++0x 以其右值引用来救援，但我们不会在最近的功能中使用 C++0x。
我们应该使用哪个字符串类？ COW 真的会成为一个问题吗？还有其他常用的字符串高效实现吗？谢谢。
编辑：我们目前不使用 unicode，而且我们不太可能需要它。然而，如果有一些东西可以轻松支持 unicode（而不是以 ICU 为代价......），那将是一个优势。
我会用std::string.
“按价值回报”问题基本上不是问题。编译器非常擅长执行返回值优化(RVO) 实际上在大多数情况下按值返回时消除了副本。如果没有，您通常可以调整该功能。
COW已被拒绝，原因是：它无法扩展（很好）并且所希望的速度增加尚未真正测量（参见 Herb Sutter 的article http://www.gotw.ca/publications/optimizations.htm）。原子操作并不像看上去那么便宜。对于单处理器单核来说这很容易，但现在多核已成为商品，并且多处理器已广泛使用（用于服务器）。在这种分布式架构中，存在多个需要同步的缓存，并且架构越分布式，原子操作的成本就越高。
Does CString实施小字符串优化？这是一个简单的技巧，允许字符串不为小字符串（通常是几个字符）分配任何内存。非常有用，因为事实证明大多数字符串实际上都很小，您的应用程序中有多少字符串长度小于 8 个字符？
所以，除非你向我提供一个真正的基准，清楚地显示使用时的净收益CString，我更愿意坚持标准：它是标准的，并且可能得到更好的优化。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
