在 C++ 中使用哪些字符串类？

Question

我们有一个用 C++ (MFC) 编写的多线程桌面应用程序。目前开发人员使用 CString 或 std::string，可能取决于他们的心情。所以我们想选择一个实现（可能不是这两个）。

MFC 的 CString 基于写时复制 (COW) 习惯用法，有些人会声称这在多线程环境中是不可接受的（可能参考 本文）。我不相信这样的说法，因为原子计数器似乎相当快，而且这种开销在某种程度上可以通过减少内存重新分配来补偿。

我了解到 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 为代价......），那将是一个优势。

Answer 1

我会使用std::string。

• 促进与 MFC 解耦
• 更好地与现有 C++ 库交互

“按值返回”问题基本上不是问题。编译器非常擅长执行返回值优化 (RVO)，这实际上在大多数情况下在按值返回时消除了副本。如果没有，您通常可以调整该功能。

COW 已被拒绝，原因是：它无法扩展（很好），而且所希望的速度提升尚未得到真正测量（参见 Herb Sutter 的 文章）。原子操作并不像看上去那么便宜。对于单处理器单核来说这很容易，但现在多核已成为商品，并且多处理器已广泛使用（用于服务器）。在这种分布式架构中，存在多个需要同步的缓存，并且架构越分布式，原子操作的成本就越高。

CString 是否实现了小字符串优化？这是一个简单的技巧，允许字符串不为小字符串（通常是几个字符）分配任何内存。非常有用，因为事实证明大多数字符串实际上都很小，您的应用程序中有多少字符串长度小于 8 个字符？

因此，除非您向我提供一个真正的基准，清楚地显示使用 CString 的净收益，否则我宁愿坚持使用标准：它是标准的，并且可能会得到更好的优化。

Answer 2

事实上，答案可能是“视情况而定”。但是，如果您使用 MFC，恕我直言，使用 CString 会更好。此外，您还可以将 CString 与 STL 容器一起使用。但是，这会导致另一个问题，我应该使用 stl 容器还是带有 CString 的 MFC 容器？使用 CString 将为您的应用程序提供灵活性，例如在 unicode 转换中。

编辑：此外，如果您使用 WIN32 api 调用，CString 转换会更容易。

编辑：CString 有一个 GetBuffer() 和有关允许您直接修改缓冲区的方法。

编辑：我在 SQLite 包装器中使用了 CString，并且格式化 CString 更容易。

    bool RS::getString(int idx, CString& a_value) {

//bla bla

        if(getDB()->getEncoding() == IDatabase::UTF8){
            a_value.Format(_T("%s"), sqlite3_column_text(getCommand()->getStatement(), idx));
        }else{
            a_value.Format(_T("%s"), sqlite3_column_text16(getCommand()->getStatement(), idx));
        }
        return true;
}

Answer 3

我不知道任何其他常见的字符串实现 - 它们都受到 C++03 中相同语言的限制。要么它们提供一些特定的东西，比如 ICU 组件如何非常适合 Unicode，它们真的像 CString 一样古老，要么 std::string 胜过它们。

但是，您可以使用 MSVC9 SP1 STL 使用的相同技术，即“交换化”，这是有史以来命名最搞笑的优化。

void func(std::string& ref) {
    std::string retval;
    // ...
    std::swap(ref, retval); // No copying done here.
}

如果您滚动了一个自定义字符串类，该类没有在其默认构造函数中分配任何内容（或检查了您的 STL 实现），那么对其进行交换优化将保证没有多余的分配。例如，我的 MSVC STL 使用 SSO，并且默认情况下不分配任何堆内存，因此通过交换上述内容，我不会获得冗余分配。

只需不使用昂贵的堆分配，您也可以显着提高性能。有一些专为临时分配而设计的分配器，您可以用自定义分配器替换您最喜欢的 STL 实现中使用的分配器。你可以从 Boost 获得对象池之类的东西，或者滚动内存竞技场。与普通的新分配相比，您可以获得十倍更好的性能。

Answer 4

我建议做出“每个 DLL”的决定。如果您的 DLL 严重依赖于 MFC（例如 GUI 层），并且需要使用 CString 参数进行大量 MFC 调用，请使用 CString。如果您的 DLL 中您要使用的唯一来自 MFC 的内容是 CString 类，请改用 std::string 。当然，您需要两个类之间的转换函数，但我怀疑您已经解决了这个问题。

Answer 5

我说总是选择std::string。如前所述，RVO 和 NVRO 将使通过副本返回变得便宜，并且当您最终切换到 C++0x 时，您可以从移动语义中获得不错的性能提升，而无需执行任何操作。如果你想获取任何代码并在非 ATL/MFC 项目中使用它，你不能使用 CString，但 std::string 会在那里，所以你会更容易时间。最后，您在评论中提到您使用 STL 容器而不是 MFC 容器（好举动）。为什么不保持一致并使用 STL 字符串呢？

Answer 6

我建议使用 std::basic_string 作为通用字符串模板库，除非有充分的理由不这样做。我说 basic_string 是因为如果您处理 16 位字符，您将使用 wstring。

如果您要使用 TCHAR，您可能应该将 tstring 定义为 basic_string，并且可能希望为其实现一个特征类以使用 _tcslen 等函数。

Answer 7

std::string 通常是引用计数的，因此值传递仍然是一种廉价的操作（对于 C++0x 中的右值引用更是如此）。仅当有多个引用指向它们的字符串时才会触发 COW，即：

std::string foo("foo");
std::string bar(foo);
foo[0] = 'm';

将经过 COW 路径。由于 COW 发生在 operator[] 内部，您可以通过使用其（非常量）operator[]() 或 强制字符串使用私有缓冲区begin() 方法。