为什么在C++中使用c字符串？

Question

现在有没有什么好的理由在C++中使用C字符串？我的教科书在某些时候在例子中使用它们，我真的觉得使用std :: string会更容易。

Answer 1

的唯一原因，我不得不使用它们是与用C风格的字符串的第三方库交互时。也可能有深奥的情况下，您会使用出于性能方面的空调风格的字符串，但更多的，往往不是用在C++字符串的方法可能更快，因为内联和专业化等

可以使用c_str()方法很多情况下使用这些类型的API时，应该知道返回的char *是const，并且不应该通过该指针修改字符串。在这种情况下，您仍然可以使用向量<char>来代替，并且至少可以获得更轻松的内存管理。

Answer 2

因为这是如何来自众多的API /库？

Answer 3

STL字符串当然更容易使用，而且我没有看到任何不使用它们的理由。

如果你需要用一个函数库，只需要C风格的字符串作为参数进行交互，可以随时调用string类的c_str（）方法。

Answer 4

假设你的代码中有一些字符串常量，这是一个很常见的需求。最好将它们定义为C字符串而不是C++对象 - 更轻量，便携等。现在，如果要将这些字符串传递给各种函数，那么如果这些函数接受C字符串而不需要C++字符串对象。

当然，如果字符串是可变的，那么它更方便地使用C++字符串对象。

Answer 5

如果C++代码是“深”（靠近内核，严重依赖于C库等），你可能需要使用C字符串明确，以避免大量的转换和注销的std :: string的。如果你与其他语言领域（Python，Ruby等）接口，你可能会出于同样的原因。否则，使用std :: string。

Answer 6

如果函数需要常量字符串即使程序使用std :: string，CString，EString或其他地方，我仍然更喜欢使用'const char *'（或const wchar_t *）。

有一个大的代码库只是字符串的太多资源，以确保调用者将有字符串作为的std :: string和“为const char *”是最小公分母。

Answer 7

考虑到选择，通常没有理由通过C++字符串（std::string）选择原始C字符串（char*）。但是，你经常没有选择的奢侈。例如，由于历史原因，std::fstream的构造函数采用C字符串。另外，C库（你猜对了！）使用C字符串。

在您自己的C++代码中，最好使用std::string并使用c_str() function of std::string根据需要提取对象的C字符串。

Answer 8

教材配备老式的C字符串，因为许多基本功能仍然期待他们作为参数，或返回它们。此外，它还深入了解了内存中字符串的底层结构。

Answer 9

这取决于你正在使用的库。例如，使用MFC时，在处理Windows API的各个部分时使用CString通常更容易。它在Win32应用程序中似乎也比std :: string执行得更好。

但是，std :: string是C++标准的一部分，所以如果您想要更好的可移植性，请使用std :: string。

Answer 10

对于像大多数嵌入式平台这样的应用程序，您没有堆栈来存储正在操作的字符串，以及需要确定性预分配字符串缓冲区的位置。

Answer 11

c字符串不承担作为类的开销。

C字符串通常会导致更快的代码，因为他们更接近机器级

这并不是说，你不能把它们写不好的代码。它们可能会被滥用，就像其他构造一样。

由于历史原因，有大量的库房呼叫需要它们。

学习如何使用c字符串和stl字符串，并在每个字符串有意义时使用它们。

Answer 12

通常的原因是您喜欢在字符串处理中编写缓冲区溢出。计数字符串优于终止字符串，很难看出C设计者为什么使用终止字符串。那是一个糟糕的决定;现在这是一个糟糕的决定。

Answer 13

内存控制。我最近不得不在大型多线程应用程序中处理大小为200-300 MB的字符串（实际上是数据库中的斑点）。这种情况下，只有一个字符串的副本可能会破坏32位地址空间。我不得不知道存在多少个字符串的副本。尽管我是STL传道者，但我使用了char *，因为它给了我保证没有额外的内存或者甚至额外的副本分配。我确切知道需要多少空间。

除此之外，标准的STL字符串处理没有在字符串处理/解析的一些很棒的C函数上丢失。值得庆幸的是，std :: string具有用于const访问内部缓冲区的c_str（）方法。要使用printf（），你仍然必须使用char *（C++团队的一个疯狂的想法是不包含printf-like功能，这是C中最有用的函数之一。我希望boost :: format将会很快被列入STL

Answer 14

一对夫妇更多的内存控制调：

C字符串是POD类型，这样他们就可以在你的应用程序的只读数据段分配如果要声明，在定义std::string常数如果你的应用程序有很多常量字符串（例如，如果你已经生成了使用常量字符串的C++代码），那么C字符串可能更适用于这个名字空间范围，因此编译器会生成额外的代码，这些代码在main()之前运行，为每个常量调用std::string构造函数。是情况。

std::string的一些实现支持名为SSO（“短字符串优化”或“小字符串优化”）的功能，其中std::string类包含长达一定长度的字符串存储。这增加了std::string的大小，但通常会显着降低自由存储分配/释放的频率，从而提高性能。如果您的std::string的实现不支持SSO，那么在堆栈上构建一个空的std::string仍将执行免费存储分配。如果是这种情况，使用临时堆栈分配的C字符串可能对使用字符串的性能严重的代码有帮助。当然，当你这样做时，你必须小心，不要在脚下自己射伤。

Answer 15

一些帖子提到内存的担忧。这可能是回避std :: string的一个很好的理由，但char *可能不是最好的替代品。它仍然是面向对象的语言。你自己的字符串类可能比char *更好。它甚至可能更高效 - 例如，您可以应用小字符串优化。

以我为例，我试图让有关1GB值得串出一个2GB的文件中，他们的东西在记录约60场和不同领域的然后排序他们7次。我的前辈代码花了25个小时char *，我的代码在1小时内运行。

Answer 16

1）“字符串常量”是C字符串（常量字符*），将其转换为常量的std :: string &是运行时间过程中，未必简单的或优化的。 2）fstream库使用c风格的字符串来传递文件名。

我的经验法则是通过const std :: string &如果我要将数据用作std :: string（比如，当我将它们存储到一个向量中），并且在其他情况下使用const char * 。

Answer 17

花费很远很远，太多的时间调试初始化规则和在多种平台上，我们需要的静态字符串是为const char *每一个可以想象的字符串后执行。

花费很长时间，太多时间调试坏char *代码和内存泄漏我建议所有非静态字符串都是某种类型的字符串对象......直到分析表明您可以并应该做得更好; - ）

Answer 18

遗留代码，不知道性病::字符串。另外，在C++ 11打开带有std :: ifstream或std :: ofstream的文件之前，只能使用const char *作为文件名的输入。