在 C++ 标准库中使用 C 字符串
Use of C-strings in C++ standard library
我想知道在 C++ 标准库中使用 C 字符串的原因是什么？直觉上，在标准库中使用 std::string 是有意义的（例如 fstream）。
每当我想写一些好看的 C++ 代码时，我就不确定我是应该从 C 字符串开始，使用 std::strings 并在需要时用 c_str() 转换它们，还是使用一些完全不同的方法。
在实践中，所有字符串 类 都可以与 C 字符串相互转换，并且在底层，与 OS API 不同的是，C 字符串占主导地位。
因此 要求 std::basic_string 变体将要求程序员支付（转换成本，如果没有别的，还有头文件和库依赖项）他们的东西可能不会使用。在使用 Qt 或 MFC 等框架构建的特定应用程序中，倾向于使用该框架的字符串类型。
更值得注意的是，IMO，接受 std::string 的地方很少或根本不支持 std::wstring。实际上不包括 Windows，其中文件名是 UTF-16 编码的。当 Boost 文件系统最终进入标准库时，我们会遇到一个奇怪的情况（我记得提案中有关于条件支持的语言，其中条件 = Windows）。
你的问题太笼统了，我只能笼统回答。
C++ 标准库的很多部分并没有很好地与 std::string 集成，因为两者是在 运行 独立开发的，直到 1998 年才标准化。
这在最近几年有所改进，在 C++11 中 std::fstream 被赋予了采用 std::string 的构造函数。
其他仍然可以使用 char 数组的领域是当只需要一个简单的字符序列并且没有字符串功能时；强制动态分配和诸如此类的东西对用户来说是不友好的。
According to Stroustrup，C++ 的 C 兼容性是一个关键的语言设计决策。这就是 C 字符串最初进入该语言的方式。正是在那个时候，一些库函数开始接受 C 字符串作为它们的参数。
但是，随着语言及其标准库的成熟，许多函数中添加了替换 C 字符串的重载，包括您在 post.[=12= 中提到的 std::fstream 的构造函数]
此时人们可能想要使用 C 字符串的主要原因是与 C 库的互操作性。
我没有参与 C++ 标准库的设计，所以我不能说为什么做出任何特定的决定，但我可以合理化设计决策的（缺点）优势。
C++ 旨在与 C 互操作，处理 C 通常意味着处理 C 字符串。 C 字符串仍然有用，有时是唯一的选择。
现在，C++ 可以提供一个标准库接口，它要求您将 const std::string<char>& 传递给 std::fstream 构造函数之类的东西。但这将迫使所有用户将他们所有的 C 字符串转换为 std::string，这需要复制整个缓冲区，这是低效的。如果我可以一概而论，许多 C++ 用户非常关心性能，所以从他们的角度来看这不是一件好事。
从std::string得到一个C字符串是微不足道的，所以C++标准库的设计有提供一个接受C字符串的接口的选项，允许用户使用他们的C字符串无需转换，但仍可让 std::string 的用户轻松使用界面。这是在 std::fstream 构造函数的情况下在标准的原始版本中选择的内容。
因为C++支持重载，C++标准库的设计也有为C字符串和std::string提供重载的选项。这样做的好处是 std::string 的用户稍微简单一些，但缺点是 API 稍微膨胀。在 C++11 修订版中，接受 const std::string& 的重载被添加到 std::fstream 构造函数中。
Whenever I want to write some good-looking C++ code, I become unsure whether I should start with C-strings
那么让我向您保证：在 C 字符串上使用 std::string 几乎总是一个不错的选择。典型的例外（但不是唯一的）是与 C 库的交互。
我想知道在 C++ 标准库中使用 C 字符串的原因是什么？直觉上，在标准库中使用 std::string 是有意义的（例如 fstream）。
每当我想写一些好看的 C++ 代码时，我就不确定我是应该从 C 字符串开始，使用 std::strings 并在需要时用 c_str() 转换它们，还是使用一些完全不同的方法。
在实践中，所有字符串 类 都可以与 C 字符串相互转换，并且在底层，与 OS API 不同的是，C 字符串占主导地位。
因此 要求 std::basic_string 变体将要求程序员支付（转换成本，如果没有别的，还有头文件和库依赖项）他们的东西可能不会使用。在使用 Qt 或 MFC 等框架构建的特定应用程序中，倾向于使用该框架的字符串类型。
更值得注意的是，IMO，接受 std::string 的地方很少或根本不支持 std::wstring。实际上不包括 Windows，其中文件名是 UTF-16 编码的。当 Boost 文件系统最终进入标准库时，我们会遇到一个奇怪的情况（我记得提案中有关于条件支持的语言，其中条件 = Windows）。
你的问题太笼统了，我只能笼统回答。
C++ 标准库的很多部分并没有很好地与 std::string 集成，因为两者是在 运行 独立开发的，直到 1998 年才标准化。
这在最近几年有所改进，在 C++11 中 std::fstream 被赋予了采用 std::string 的构造函数。
其他仍然可以使用 char 数组的领域是当只需要一个简单的字符序列并且没有字符串功能时；强制动态分配和诸如此类的东西对用户来说是不友好的。
According to Stroustrup，C++ 的 C 兼容性是一个关键的语言设计决策。这就是 C 字符串最初进入该语言的方式。正是在那个时候，一些库函数开始接受 C 字符串作为它们的参数。
但是，随着语言及其标准库的成熟，许多函数中添加了替换 C 字符串的重载，包括您在 post.[=12= 中提到的 std::fstream 的构造函数]
此时人们可能想要使用 C 字符串的主要原因是与 C 库的互操作性。
我没有参与 C++ 标准库的设计，所以我不能说为什么做出任何特定的决定，但我可以合理化设计决策的（缺点）优势。
C++ 旨在与 C 互操作，处理 C 通常意味着处理 C 字符串。 C 字符串仍然有用，有时是唯一的选择。
现在，C++ 可以提供一个标准库接口，它要求您将 const std::string<char>& 传递给 std::fstream 构造函数之类的东西。但这将迫使所有用户将他们所有的 C 字符串转换为 std::string，这需要复制整个缓冲区，这是低效的。如果我可以一概而论，许多 C++ 用户非常关心性能，所以从他们的角度来看这不是一件好事。
从std::string得到一个C字符串是微不足道的，所以C++标准库的设计有提供一个接受C字符串的接口的选项，允许用户使用他们的C字符串无需转换，但仍可让 std::string 的用户轻松使用界面。这是在 std::fstream 构造函数的情况下在标准的原始版本中选择的内容。
因为C++支持重载，C++标准库的设计也有为C字符串和std::string提供重载的选项。这样做的好处是 std::string 的用户稍微简单一些，但缺点是 API 稍微膨胀。在 C++11 修订版中，接受 const std::string& 的重载被添加到 std::fstream 构造函数中。
Whenever I want to write some good-looking C++ code, I become unsure whether I should start with C-strings
那么让我向您保证：在 C 字符串上使用 std::string 几乎总是一个不错的选择。典型的例外（但不是唯一的）是与 C 库的交互。