C ++字符串，何时使用？

Question

现在已经有一段时间了，我一直在使用C ++进行编码，而且我认为大多数实际用C ++编写代码的人会同意最棘手的决定之一就是选择几乎令人眼花缭乱的字符串类型。我主要更喜欢ATL Cstring因其易用性和功能，但希望对可用选项进行比较研究。 我已经检查了SO并且没有找到任何帮助选择正确字符串的内容。有些网站会说明从一个字符串到另一个字符串的转换，但这不是我们想要的。

很想基于专业，性能，可移植性（Windows，Mac，Linux / Unix等），易用性/功能，多语言支持（Unicode / MBCS），缺点（如果有的话）和任何其他特殊情况。

我列出了我到目前为止遇到的字符串。我相信会有更多，所以我们可以稍后编辑它以适应其他选项。请注意，我主要在Windows上工作，因此列表反映了相同的内容：

1. char*
2. std::string
3. STL的basic_string
4. ATL的CString
5. MFC的CString
6. BSTR
7. _bstr_t
8. CComBstr

Answer 1

并不是说要对你的热情有所帮助，但实际上在一个项目中混合很多字符串类型效率很低，所以项目越大，它就越不可避免地应该在std :: string上解决（这是对类型为char的STL的basic_string实例化的typedef，而不是一个不同的实体），因为它是唯一的标准值 - 语义选项。 char *主要用于固定大小的字符串（例如字符串文字，固定大小的缓冲区）或与C接口。

为什么我说效率低？您最终会为各种字符串参数（即使是多个参数的排列）进行不必要的模板实例化。您发现自己正在调用想要将结果加载到字符串＆amp;中的函数，然后必须在其上调用.c_str（）并构造其他类型，执行冗余内存分配。甚至const std :: string＆amp;如果使用ASCIIZ char *调用（例如，对某些其他字符串类型的缓冲区），则需要一个临时字符串。当你想编写一个函数来处理特定调用者想要使用的字符串类型时，你会被推向模板，因此内联代码，更长的编译时间和重新编译依赖性（有一些方法可以缓解这种情况，但它们会变得复杂为方便或自动化，他们倾向于需要更改各种字符串类型 - 例如，转换操作符或成员函数返回一些公共接口/代理对象。

项目可能需要使用非标准字符串类型与他们想要使用的库进行交互，但是如果可能的话，您希望将其最小化并限制普遍性。

Answer 2

关于C ++字符串处理的令人遗憾的故事让我写一篇文章太令人沮丧了，但只有几点：

• ATL和MFC CString是一回事（相同的代码和所有内容）。它们在几年前合并。

• 如果你正在使用_bstr_t或CComBstr，你可能不会使用BSTR，除非是调用其他人的BSTR的API。

Answer 3

• char* - 快速，功能包括＆lt; cstring＆gt;标题，容易出错（太低级别）

• std::string - 这实际上是std::basic_string<char, char_traits<char> >的一个typedef一个美丽的东西 - 首先，它也很快。其次，你可以使用所有＆lt;算法＆gt;因为basic_string提供了迭代器。对于广泛支持，还有另一个typedef，wstring，std::basic_string<wchar_t, char_traits<wchar_t> >。这个（basic_string）是标准类型，因此绝对可移植。我会选择这个。

• ATL和MFC的CStrings甚至不提供迭代器，因此它们对我来说是可憎的，因为它们是c-strings的类包装器，它们的设计非常糟糕。 IMHO

• 不了解其余部分。

HOpe这部分信息有帮助

Answer 4

显然，只有前三个是便携式的，所以在大多数情况下它们应该是首选。如果您正在使用C ++，那么在大多数情况下应避免使用char *，因为原始指针和数组容易出错。与低级C接口，例如在系统调用或驱动程序中，是例外。默认情况下应该首选std:string，恕我直言，因为它与STL的其余部分很好地匹配。

再次，恕我直言，如果你需要与... MFC，您应该在业务逻辑中使用std::string的所有内容，并在点击WinApi函数时转换为CString。

Answer 5

2和3是相同的。 4和5也是相同的。 7和8是6的包装。因此，可以说，该列表只包含C的字符串，标准C ++的字符串，Microsoft的C ++字符串和Microsoft的COM字符串。这给出了答案：在标准C ++中，使用标准C ++字符串（std::string）