如何处理C++中的字符串?

std::string或std::wstring,具体取决于您的需要。为什么?

• 它们是标准的
• 它们是便携式的
• 他们可以处理i18n
• 他们有性能保证(按标准)
• 防止缓冲区溢出和类似攻击
• 可根据需要轻松转换为其他类型
• 很好的模板化,在减少代码膨胀和提高性能的同时,为您提供了各种各样的选项。真的?无法处理模板的编译器早已不复存在了。

一个C样式的字符数组只是在自找麻烦。有时您仍然需要处理它们(这就是std::string.c_str()的作用),但是,老实说,在C中最大的危险之一是程序员使用char*做坏事并结束缓冲区溢出。别这么做。

一个wchar_uuu t数组是相同的,只是更大。

cstring、bstr和ccombstr不是标准的,不可移植。除非绝对强迫,否则要避开它们。最理想的情况是,只需在需要时将std::string/std::wstring转换为它们,这不应该非常昂贵。

请注意,std::string只是std::basic_string的一个子级,但除非有充分的理由不使用std::string,否则最好还是使用它。真的很好。在这种情况下,让编译器负责优化。

STD::字符串 !!

他们称之为“标准”是有原因的。

基本_字符串是一个实现细节,应该忽略它。

bstr&ccombstr仅用于与COM的互操作,并且仅用于互操作的时刻。

字符串,除非我需要调用一个专门接受您列出的其他API。

这里有一篇文章比较C++中最常见的字符串类型以及如何在它们之间进行转换。 Unraveling Strings in Visual C++

如果可以使用MFC,请使用CString。否则使用std::string。另外,STD::String工作在支持标准C++的任何平台上。

当我有选择的时候(我通常不会),我倾向于使用std::string和utf-8编码(以及 UTF8 CPP 图书馆。我不太喜欢std::string,但至少它是标准的和可移植的。

不幸的是,在我从事过的几乎所有实际项目中,都有内部字符串类——它们中的大多数实际上比std::string更好,但仍然……

我是一个qt-dev,所以我当然倾向于尽可能使用qstring:。

它相当不错:符合Unicode,线程安全的隐式共享(也称为写时复制),它附带了一个API,旨在解决实际的问题(拆分、联接、替换(有无regex)、数字转换/从数字转换…)

如果我不能使用qstring,那么std::wstring。如果你坚持使用C语言,我建议你使用glib gstring。

我用 std::string (或) basic_string<TCHAR> )只要我能。它的用途非常广泛(就像 CStringT ,它是类型安全的(不像 printf )并且它在每个平台上都可用。

其他,std::wstring。

字符串是20世纪的技术。使用unicode,销售给60亿人而不是3亿人。

C样式的char数组有它们的位置,但是如果您广泛地使用它们,您会要求将调试时间浪费在一个错误上。我们有自己的字符串类,可以在我们的(嵌入式开发环境)中使用。

我们不使用std::string,因为它并不总是对我们可用。

如果您使用的是MFC,请使用CString。否则,我同意大多数其他方法,即std::string或std::wstring。

微软本可以通过在最新的MFC更新中添加std::basic_string<tchar>重载来给世界带来巨大的好处。

我喜欢使用tchar,它是根据项目设置为wchar或char定义的。 它是在tchar.h中定义的,您可以在其中找到所需函数和类型的所有相关定义。

std::string和std::wstring,如果可以的话,如果必须的话。

它们可能并不完美,但它们经过了很好的测试,被很好的理解,而且非常通用。它们与标准库的其他部分配合得很好,这也是一个巨大的奖金。

值得一提的是, stringstreams .

std::string比什么都没有要好,但它缺少诸如split、join甚至体面的格式调用之类的基本功能,这让人恼火…

Unicode是未来。不要使用char*和std::string。请) 我厌倦了本地化错误。