【发布时间】：2011-01-07 04:03:56
【问题描述】：
哪个更适合字符串文字， 标准字符串还是字符数组？
我的意思是说对于常量字符串，比如说
const char name[] = "so"; //or to use
const string name = "so";
【问题讨论】：
标签： c++ arrays string stl char
【发布时间】：2011-01-07 04:03:56
【问题描述】：
对于字符串文字，并且仅对于来自文字的字符串常量，我会使用const char[]。 std::string 的主要优点是它有免费的内存管理，但这不是字符串文字的问题。
无论如何，它是文字的实际类型，它可以直接用在任何需要旧 C 样式以空终止字符串或 C++ 字符串（开始隐式转换）的 API 中。您还可以通过使用数组而不是指针来获得编译时大小的实现。
现在，在定义函数接口时，即使打算传入常量，我也更喜欢std::string 而不是const char*，因为在后一种情况下，大小会丢失，并且可能需要重新计算。
根据我自己的经验。对于带有信息/错误消息的文字字符串，我已经习惯在每次调用日志库（使用变量参数）时写 .c_str()。
【讨论】：
你用它做什么？你的方法期望什么？
const char 在存储上更轻巧，但没有 std::string 的强大功能，也没有使用它时的安全性。但是，如果您有很多 C API，则可能是更明智的选择。
std::string 将是首选选项。
【讨论】：
-
@JPvdMerwe：剧院是正确的。如果您所做的只是将常量字符串传递给需要
const char*的函数，那么使用std::string/.c_str()毫无意义。const数组char没有构造函数调用成本，可以直接传递给函数，这使得构造和传递给函数的成本比std::string更便宜。 -
是的字符串文字，我完全同意，没有必要浪费你的处理器时间。
您应该使用更适合您的。如果没有特殊要求，我会使用std::string，因为它可以完成所有内存工作。
对于字符串文字，我会使用const char*。反对const char[] 的原因是您可以使用const char* 来初始化另一个常量。检查以下代码：
const char str1[] = "str1";
const char* str11 = "str11";
const char str2[] = str1; // <<< compile error
const char* str22 = str11; // <<< OK
字符串字面量具有静态存储期限（根据 2.13.4/2），因此指针 const char* 将在程序完成之前有效。
【讨论】：
-
如果你在许多不同的地方使用相同的字符串，由于写入时复制机制，它在许多 STL 实现中更快，这也使它比普通的 C 字符串更容易使用。除此之外，如果您需要支持多种语言，我宁愿使用 std::wstring。
-
@jdehaan：如果有（m）任何 std 库实现（不是 STL 实现，因为
std::string不是 STL 的一部分）仍然在做 COW，我会感到惊讶。在 MT 环境中，这通常会变成悲观。我认为小字符串优化（小字符串不是在堆上分配，而是在栈上）是现在普遍青睐的。 -
写时复制在大多数实现中被删除（如果仍然存在）。它在多线程环境中存在问题，因为从用户的角度来看似乎是线程安全的一些操作（它们引用不同的 std::string 的）可能不是线程安全的。考虑一个字符串被复制，每个副本传递到不同的线程进行修改。每个线程都有自己的字符串，没有共享对象，但实际上在“写时复制”内部实现中可能存在竞争条件。在许多情况下，在库中添加锁定机制会使其比普通实现慢。
-
@sbi，@dribeas，感谢您的提示，我确实仍在使用较旧的实现...我从未使用 .NET 进行项目。我看到我必须更新我对现代 STL 实现的了解。谢谢。
-
@jdehaan, @sbi 在任何情况下，将字符串文字直接传递给
string::string将复制它并且不会使用COW，假设编译器除了字符串文字之外没有特殊的内部类型const char[]和一个自嘲的 STL。
对于字符串文字，我倾向于使用const std::string 而不是const char *。因为将字符串文字传递给采用const std::string & 的函数将在每次调用它们时默默地创建字符串，而不仅仅是一个。但是，如果我主要将文字与期望 const char * 的函数一起使用，我将改用它。
我倾向于使用std::string 来使用 api。
当然，如果我使用 unicode，我会使用 std::wstring 和 wchar_t。
【讨论】：
-
我对 unicode 做了同样的假设，但这很有趣：utf8everywhere.org。事实证明，wchar_t 是 unicode 历史上更简单时期的遗物，Win32 API 也是 WCHAR 原生的。如果你坚持使用 UTF-8 和 std::string，生活可能会更好。