blocks|key|760426|text|我不得不使用它们的唯一原因是在与使用C样式字符串的第三方库交互时。也可能有一些深奥的情况，出于性能原因，您可能会使用C样式字符串，但通常情况下，由于内联和专门化等原因，对C%2B%2B字符串使用方法可能会更快。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|760427|在使用这些类型的API时，您可以在许多情况下使用c_str()方法，但是您应该知道返回的char+*是const，并且不应该通过该指针修改字符串。在这种情况下，您仍然可以使用向量，并且至少可以获得更容易的内存管理的好处。|offset|length|style|CODE|760428|entityMap|0|LINK|mutability|MUTABLE|url|http://en.cppreference.com/w/cpp/string/basic_string/c_str^0|0|O|7|O|7|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@$D|R|E|S|F|G]]|9|@$D|T|E|U|1|V]]|A|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

The only reasons I've had to use them is when interfacing with 3rd party libraries that use C style strings. There might also be esoteric situations where you would use C style strings for performance reasons, but more often than not, using methods on C++ strings is probably faster due to inlining and specialization, etc.

You can use the <a href="http://en.cppreference.com/w/cpp/string/basic_string/c_str" rel="nofollow noreferrer"><code>c_str()</code></a> method in many cases when working with those sort of APIs, but you should be aware that the char * returned is const, and you should not modify the string via that pointer. In those sort of situations, you can still use a vector&lt;char&gt; instead, and at least get the benefit of easier memory management.

blocks|key|3014860|text|更多的内存控制注意事项：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3014861|C字符串是POD类型，因此可以在应用程序的只读数据段中分配它们。如果在命名空间范围内声明和定义std::string常量，编译器将生成在调用每个常量的std::string构造函数的main()之前运行的附加代码。如果您的应用程序有许多常量字符串(例如，如果您已经生成了使用常量字符串的C%2B%2B代码)，则在这种情况下，C字符串可能更可取。|offset|length|style|CODE|3014862|std::string的一些实现支持一种称为SSO+(“短字符串优化”或“小字符串优化”)的特性，其中std::string类包含对特定长度字符串的存储。这增加了std::string的大小，但通常会显著降低空闲存储分配/释放的频率，从而提高性能。如果您的std::string实现不支持单点登录，那么在堆栈上构造一个空的std::string仍然会执行空闲存储分配。如果是这种情况，对于使用字符串的性能关键型代码，使用临时堆栈分配的C字符串可能会很有帮助。当然，当你这样做的时候，你必须小心不要伤到自己的脚。|3014863|entityMap^0|0|1B|B|23|B|2J|6|0|0|B|1F|B|29|B|3K|B|4H|B|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@$D|U|E|V|F|G]|$D|W|E|X|F|G]|$D|Y|E|Z|F|G]|$D|10|E|11|F|G]|$D|12|E|13|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|K|$]]

A couple more memory control notes:

C strings are POD types, so they can be allocated in your application's read-only data segment. If you declare and define <code>std::string</code> constants at namespace scope, the compiler will generate additional code that runs before <code>main()</code> that calls the <code>std::string</code> constructor for each constant. If your application has many constant strings (e.g. if you have generated C++ code that uses constant strings), C strings may be preferable in this situation.

Some implementations of <code>std::string</code> support a feature called SSO ("short string optimization" or "small string optimization") where the <code>std::string</code> class contains storage for strings up to a certain length. This increases the size of <code>std::string</code> but often significantly reduces the frequency of free-store allocations/deallocations, improving performance. If your implementation of <code>std::string</code> does not support SSO, then constructing an empty <code>std::string</code> on the stack will still perform a free-store allocation. If that is the case, using temporary stack-allocated C strings may be helpful for performance-critical code that uses strings. Of course, you have to be careful not to shoot yourself in the foot when you do this.

blocks|key|5270025|text|因为这就是它们来自众多API/库的方式？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5270026|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Because that's how they come from numerous API/libraries?

blocks|key|3859211|text|假设您的代码中有一些字符串常量，这是一个非常常见的需求。将这些字符串定义为C字符串比定义为C%2B%2B对象更好--更轻量级、更可移植等。现在，如果要将这些字符串传递给各种函数，最好这些函数接受C字符串，而不是需要C%2B%2B字符串对象。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3859212|当然，如果字符串是可变的，那么使用C%2B%2B+string对象要方便得多。|3859213|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Let's say you have some string constants in your code, which is a pretty common need. It's better to define these as C strings than as C++ objects -- more lightweight, portable, etc. Now, if you're going to be passing these strings to various functions, it's nice if these functions accept a C string instead of requiring a C++ string object.

Of course, if the strings are mutable, then it's much more convenient to use C++ string objects.

blocks|key|3014507|text|如果一个函数需要一个常量字符串常量，我仍然喜欢使用'const+char*‘(或者常量wchar_t*)，即使程序使用std：：，CString，EString或者其他任何东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3014508|在大型代码库中有太多的字符串源，无法确保调用者将字符串作为std::string，而'const+char*‘是最小的公分母。|3014509|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If a function needs a constant string I still prefer to use 'const char*' (or const wchar_t*) even if the program uses std::string, CString, EString or whatever elsewhere.

There are just too many sources of strings in a large code base to be sure the caller will have the string as a std::string and 'const char*' is the lowest common denominator.

blocks|key|3014590|text|教科书提供了老式的C字符串，因为许多基本函数仍然希望它们作为参数，或者返回它们。此外，它还可以深入了解内存中字符串的底层结构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3014591|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Textbooks feature old-school C strings because many basic functions still expect them as arguments, or return them. Additionally, it gives some insight into the underlying structure of the string in memory.

blocks|key|3859598|text|内存控制。在一个大型多线程应用程序中，我最近不得不处理大约200-300MB大小的字符串(实际上是数据库中的blobs+)。在这种情况下，字符串的一个或多个副本可能会破坏32位地址空间。我必须确切地知道这个字符串有多少个副本。尽管我是STL布道者，但我还是使用了char+*，因为它保证不会分配额外的内存，甚至不会分配额外的副本。我确切地知道它需要多少空间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3859599|除此之外，标准STL字符串处理遗漏了一些用于字符串处理/解析的优秀C函数。值得庆幸的是，std::string具有c_str()方法，用于常量访问内部缓冲区。要使用printf()，你仍然必须使用char+*(+C%2B%2B团队没有包含类似printf的功能，这是一个多么疯狂的想法，这是C语言中最有用的函数之一。我希望boost::format很快就会包含在STL中。|3859600|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Memory control. I recently had to handle strings (actually blobs from a database) about 200-300 MB in size, in a massively multithreaded application. It was a situation where just-one-more copy of the string might have burst the 32bit address space. I had to know exactly how many copies of the string existed. Although I'm an STL evangelist, I used char * then because it gave me the guarantee that no extra memory or even extra copy was allocated. I knew exactly how much space it would need.

Apart from that, standard STL string processing misses out on some great C functions for string processing/parsing. Thankfully, std::string has the c_str() method for const access to the internal buffer. To use printf() you still have to use char * though (what a crazy idea of the C++ team to not include (s)printf-like functionality, one of the most useful functions EVER in C. I hope boost::format will soon be included in the STL.

blocks|key|5270274|text|如果C%2B%2B代码很“深”(接近内核，严重依赖C库，等等)您可能希望显式地使用C字符串，以避免在std::string之间进行大量的转换。当然，如果您正在与其他语言领域(Python、Ruby等)进行交互。出于同样的原因，您可能会这样做。否则，使用std::string。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5270275|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If the C++ code is "deep" (close to the kernel, heavily dependent on C libraries, etc.) you may want to use C strings explicitly to avoid lots of conversions in to and out of std::string. Of, if you're interfacing with other language domains (Python, Ruby, etc.) you might do so for the same reason. Otherwise, use std::string.

blocks|key|760724|text|一些帖子提到了内存问题。这可能是避免使用std::string的一个很好的理由，但是char*可能不是最好的替代品。它仍然是一种面向对象的语言。你自己的字符串类可能比char*更好。它甚至可能更有效率--例如，你可以应用小字符串优化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|760725|在我的例子中，我试图从一个2+1GB的文件中获得大约1+1GB的字符串，将它们填充到大约60个字段的记录中，然后对它们进行7次不同字段的排序。我的前辈的代码使用char*花了25个小时，我的代码在1小时内运行。|760726|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Some posts mention memory concerns. That might be a good reason to shun std::string, but char* probably is not the best replacement. It's still an OO language. Your own string class is probably better than a char*. It may even be more efficient - you can apply the Small String Optimization, for instance. 

In my case, I was trying to get about 1GB worth of strings out of a 2GB file, stuff them in records with about 60 fields and then sort them 7 times of different fields. My predecessors code took 25 hours with char*, my code ran in 1 hour.

blocks|key|3014974|text|1)+"string+constant“是一个C字符串(const+char+*)，将其转换为const+std::+string+&是运行时过程，不一定简单或优化。2)+fstream库使用c风格的字符串传递文件名。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3014975|我的经验法则是传递const+std::string&如果我无论如何都要将数据作为std::string使用(比如，当我将它们存储在向量中时)，在其他情况下传递const+char+*。|3014976|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

1) "string constant" is a C string (const char *), converting it to const std::string&amp; is run-time process, not necessarily simple or optimized.
2) fstream library uses c-style strings to pass file names.

My rule of thumb is to pass const std::string&amp; if I am about to use the data as std::string anyway (say, when I store them in a vector), and const char * in other cases.

blocks|key|760821|text|在花费大量时间调试初始化规则和在几个平台上的每个可以想到的字符串实现之后，我们要求静态字符串为常量char*。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|760822|在花了太多时间调试坏的char*代码和内存泄漏之后，我建议所有非静态字符串都是某种类型的字符串对象……直到分析显示您可以并且应该做更好的事情;-)|760823|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

After spending far, far, too much time debugging initialization rules and every conceivable string implementation on several platforms we require static strings to be const char*.

After spending far, far, too much time debugging bad char* code and memory leaks I suggest that all non-static strings be some type of string object ... until profiling shows that you can and should do something better ;-)

blocks|key|5271029|text|不知道std::string的遗留代码。此外，在C%2B%2B11之前，使用std::ifstream或std::ofstream打开文件只能使用const+char*作为文件名的输入。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5271030|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Legacy code that doesn't know of std::string. Also, before C++11 opening files with std::ifstream or std::ofstream was only possible with const char* as an input to the file name.

blocks|key|3859380|text|如果可以选择，通常没有理由选择原始C字符串(char*)而不是C%2B%2B字符串(std::string)。然而，你通常没有选择的余地。例如，由于历史原因，std::fstream的构造函数使用C字符串，而且，C库(你猜对了！)使用C字符串。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3859381|在您自己的C%2B%2B代码中，最好使用std::string，并根据需要使用c_str()+function+of+std::string提取对象的C字符串。|3859382|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cplusplus.com/reference/string/string/c_str.html^0|M|5|12|B|23|C|0|G|B|Z|7|1J|B|Z|V|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@$9|13|A|14|1|15]]|E|$]]|$1|H|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

Given the choice, there is generally no reason to choose primitive C strings (<code>char*</code>) over C++ strings (<code>std::string</code>). However, often you don't have the luxury of choice. For instance, <code>std::fstream</code>'s constructors take C strings, for historical reasons. Also, C libraries (you guessed it!) use C strings.

In your own C++ code it is best to use <code>std::string</code> and extract the object's C string as needed by using the <a href="http://www.cplusplus.com/reference/string/string/c_str.html" rel="nofollow noreferrer"><code>c_str()</code> function of <code>std::string</code></a>.

blocks|key|760577|text|这取决于您正在使用的库。例如，在使用MFC时，使用Windows+API的各个部分通常更容易使用CString。在Win32应用程序中，它似乎也比std::string执行得更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|760578|但是，std::string是C%2B%2B标准的一部分，所以如果您想要更好的可移植性，请使用std::string。|760579|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library^0|I|3|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

It depends on the libraries you're using. For example, when working with the <a href="http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library" rel="nofollow noreferrer">MFC</a>, it's often easier to use CString when working with various parts of the Windows API. It also seems to perform better than std::string in Win32 applications.

However, std::string is part of the C++ standard, so if you want better portability, go with std::string.

blocks|key|3859521|text|适用于诸如大多数嵌入式平台这样的应用程序，在这些应用程序中，您没有足够的堆来存储被操作的字符串，并且需要对字符串缓冲区进行确定性预分配。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3859522|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For applications such as most embedded platforms where you do not have the luxury of a heap to store the strings being manipulated, and where deterministic preallocation of string buffers is required.

blocks|key|3014728|text|C字符串没有作为类的开销。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3014729|C字符串通常可以产生更快的代码，因为它们更接近于机器级别|3014730|这并不是说，你不能用它们编写糟糕的代码。它们可能会被误用，就像其他任何构造一样。|3014731|由于历史原因，有大量的图书馆调用需要它们。|3014732|学习使用c字符串和stl字符串，并在有意义的时候使用它们。|3014733|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

c strings don't carry the overhead of being a class.

c strings generally can result in faster code, as they are closer to the machine level

This is not to say, you can't write bad code with them. They can be misused, like every other construct.

There is a wealth of libary calls that demand them for historical reasons.

Learn to use c strings, and stl strings, and use each when it makes sense to do so.

blocks|key|763224|text|STL字符串当然更容易使用，我看不出有任何理由不使用它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|763225|如果需要与只接受C样式字符串作为参数的库进行交互，则始终可以调用string类的c_str()方法。|763226|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

STL strings are certainly far easier to use, and I don't see any reason to not use them.

If you need to interact with a library that only takes C-style strings as arguments, you can always call the c_str() method of the string class.

blocks|key|760631|text|这样做的通常原因是，您喜欢在字符串处理中编写缓冲区溢出。计数字符串比终止字符串优越得多，很难理解为什么C设计者会使用终止字符串。这在当时是一个糟糕的决定，现在也是一个糟糕的决定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|760632|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The usual reason to do it is that you enjoy writing buffer overflows in your string handling. Counted strings are so superior to terminated strings it's hard to see why the C designers ever used terminated strings. It was a bad decision then; it's a bad decision now.

Is there any good reason to use C-strings in C++ nowadays? My textbook uses them in examples at some points, and I really feel like it would be easier just to use a std::string.

Why use c strings in c++?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

现在在C++中使用C-strings有什么好的理由吗？我的教科书在某些情况下在示例中使用了它们，我真的觉得只使用std::string会更容易。

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

回答 18

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

回答 18

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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