As much as I love C and C++, I can't help but scratch my head at the choice of null terminated strings:

尽管我非常喜欢C和C++，但对于选择以空值结尾的字符串，我还是忍不住摸不着头脑：

• Length prefixed (i.e. Pascal) strings existed before C


• Length prefixed strings make several algorithms faster by allowing constant time length lookup.


• Length prefixed strings make it more difficult to cause buffer overrun errors.


• Even on a 32 bit machine, if you allow the string to be the size of available memory, a length prefixed string is only three bytes wider than a null terminated string. On 16 bit machines this is a single byte. On 64 bit machines, 4GB is a reasonable string length limit, but even if you want to expand it to the size of the machine word, 64 bit machines usually have ample memory making the extra seven bytes sort of a null argument. I know the original C standard was written for insanely poor machines (in terms of memory), but the efficiency argument doesn't sell me here.


• Pretty much every other language (i.e. Perl, Pascal, Python, Java, C#, etc) use length prefixed strings. These languages usually beat C in string manipulation benchmarks because they are more efficient with strings.


• C++ rectified this a bit with the std::basic_string template, but plain character arrays expecting null terminated strings are still pervasive. This is also imperfect because it requires heap allocation.


• Null terminated strings have to reserve a character (namely, null), which cannot exist in the string, while length prefixed strings can contain embedded nulls.

Several of these things have come to light more recently than C, so it would make sense for C to not have known of them. However, several were plain well before C came to be. Why would null terminated strings have been chosen instead of the obviously superior length prefixing?

其中有几件事比C更晚曝光，所以C不知道它们是有道理的。然而，有几个在C出现之前就已经很普通了。为什么选择以空值结尾的字符串，而不是使用明显优越的长度前缀？

EDIT: Since some asked for facts (and didn't like the ones I already provided) on my efficiency point above, they stem from a few things:

编辑：由于一些人就我上面的效率点询问事实(而且不喜欢我已经提供的事实)，他们源于以下几点：

• Concat using null terminated strings requires O(n + m) time complexity. Length prefixing often require only O(m).


• Length using null terminated strings requires O(n) time complexity. Length prefixing is O(1).


• Length and concat are by far the most common string operations. There are several cases where null terminated strings can be more efficient, but these occur much less often.

From answers below, these are some cases where null terminated strings are more efficient:

从以下答案可以看出，在以下情况下，以空值结尾的字符串效率更高：

• When you need to cut off the start of a string and need to pass it to some method. You can't really do this in constant time with length prefixing even if you are allowed to destroy the original string, because the length prefix probably needs to follow alignment rules.


• In some cases where you're just looping through the string character by character you might be able to save a CPU register. Note that this works only in the case that you haven't dynamically allocated the string (Because then you'd have to free it, necessitating using that CPU register you saved to hold the pointer you originally got from malloc and friends).

None of the above are nearly as common as length and concat.

以上这些都不像Long和Conat那样常见。

There's one more asserted in the answers below:

在下面的回答中，还有一个断言：

• You need to cut off the end of the string

but this one is incorrect -- it's the same amount of time for null terminated and length prefixed strings. (Null terminated strings just stick a null where you want the new end to be, length prefixers just subtract from the prefix.)

但是这个是不正确的--对于空值终止和长度前缀的字符串来说，它的时间是相同的。(以空值结尾的字符串只需将空值粘贴到您想要的新结尾的位置，长度前缀只需从前缀中减去。)

优秀答案推荐

From the horse's mouth

从马的嘴里

None of BCPL, B, or C supports
character data strongly in the
language; each treats strings much
like vectors of integers and
supplements general rules by a few
conventions. In both BCPL and B a
string literal denotes the address of
a static area initialized with the
characters of the string, packed into
cells. In BCPL, the first packed byte
contains the number of characters in
the string; in B, there is no count
and strings are terminated by a
special character, which B spelled
*e. This change was made partially
to avoid the limitation on the length
of a string caused by holding the
count in an 8- or 9-bit slot, and
partly because maintaining the count
seemed, in our experience, less
convenient than using a terminator.

_{Dennis M Ritchie, Development of the C Language}

丹尼斯·M·里奇，C语言的发展

C doesn't have a string as part of the language. A 'string' in C is just a pointer to char. So maybe you're asking the wrong question.

C语言没有字符串作为语言的一部分。C中的“字符串”只是一个指向字符的指针。所以也许你问错了问题。

"What's the rationale for leaving out a string type" might be more relevant. To that I would point out that C is not an object oriented language and only has basic value types. A string is a higher level concept that has to be implemented by in some way combining values of other types. C is at a lower level of abstraction.

“省略字符串类型的理由是什么”可能更相关。对此，我想指出的是，C不是一种面向对象的语言，只有基本的值类型。字符串是一个更高级别的概念，它必须通过以某种方式组合其他类型的值来实现。C处于较低的抽象级别。

in light of the raging squall below:

I just want to point out that I'm not trying to say this is a stupid or bad question, or that the C way of representing strings is the best choice. I'm trying to clarify that the question would be more succinctly put if you take into account the fact that C has no mechanism for differentiating a string as a datatype from a byte array. Is this the best choice in light of the processing and memory power of todays computers? Probably not. But hindsight is always 20/20 and all that :)

我只是想指出，我并不是想说这是一个愚蠢或糟糕的问题，也不是说C语言表示字符串的方式是最佳选择。我试图澄清的是，如果考虑到C没有将字符串作为数据类型与字节数组区分的机制，那么这个问题会更简洁。鉴于当今计算机的处理和存储能力，这是不是最好的选择？大概不会吧。但后见之明总是20/20和所有这些：)

The question is asked as a Length Prefixed Strings (LPS) vs zero terminated strings (SZ) thing, but mostly expose benefits of length prefixed strings. That may seem overwhelming, but to be honest we should also consider drawbacks of LPS and advantages of SZ.

这个问题是作为长度前缀字符串(LPS)与零终止字符串(SZ)的问题提出的，但主要揭示了长度前缀字符串的好处。这可能看起来势不可挡，但老实说，我们也应该考虑到LPS的缺点和SZ的优势。

As I understand it, the question may even be understood as a biased way to ask "what are the advantages of Zero Terminated Strings ?".

根据我的理解，这个问题甚至可能被理解为一种有偏见的方式，即询问“零终止字符串的优势是什么？”

Advantages (I see) of Zero Terminated Strings:

零终止字符串的优势(我明白了)：

• very simple, no need to introduce new concepts in language, char
  arrays/char pointers can do.


• the core language just include minimal syntaxic sugar to convert
  something between double quotes to a
  bunch of chars (really a bunch of
  bytes). In some cases it can be used
  to initialize things completely
  unrelated with text. For instance xpm
  image file format is a valid C source
  that contains image data encoded as a
  string.


• by the way, you can put a zero in a string literal, the compiler will
  just also add another one at the end of the literal: "this\0is\0valid\0C".
  Is it a string ? or four strings ? Or a bunch of bytes...


• flat implementation, no hidden indirection, no hidden integer.


• no hidden memory allocation involved (well, some infamous non
  standard functions like strdup
  perform allocation, but that's mostly
  a source of problem).


• no specific issue for small or large hardware (imagine the burden to
  manage 32 bits prefix length on 8
  bits microcontrollers, or the
  restrictions of limiting string size
  to less than 256 bytes, that was a problem I actually had with Turbo Pascal eons ago).


• implementation of string manipulation is just a handful of
  very simple library function


• efficient for the main use of strings : constant text read
  sequentially from a known start
  (mostly messages to the user).


• the terminating zero is not even mandatory, all necessary tools
  to manipulate chars like a bunch of
  bytes are available. When performing
  array initialisation in C, you can
  even avoid the NUL terminator. Just
  set the right size. char a[3] =
"foo"; is valid C (not C++) and
  won't put a final zero in a.


• coherent with the unix point of view "everything is file", including
  "files" that have no intrinsic length
  like stdin, stdout. You should remember that open read and write primitives are implemented
  at a very low level. They are not library calls, but system calls. And the same API is used
  for binary or text files. File reading primitives get a buffer address and a size and return
  the new size. And you can use strings as the buffer to write. Using another kind of string
  representation would imply you can't easily use a literal string as the buffer to output, or
  you would have to make it have a very strange behavior when casting it to char*. Namely
  not to return the address of the string, but instead to return the actual data.


• very easy to manipulate text data read from a file in-place, without useless copy of buffer,
  just insert zeroes at the right places (well, not really with modern C as double quoted strings are const char arrays nowaday usually kept in non modifiable data segment).


• prepending some int values of whatever size would implies alignment issues. The initial
  length should be aligned, but there is no reason to do that for the characters datas (and
  again, forcing alignment of strings would imply problems when treating them as a bunch of
  bytes).


• length is known at compile time for constant literal strings (sizeof). So why would
  anyone want to store it in memory prepending it to actual data ?


• in a way C is doing as (nearly) everyone else, strings are viewed as arrays of char. As array length is not managed by C, it is logical length is not managed either for strings. The only surprising thing is that 0 item added at the end, but that's just at core language level when typing a string between double quotes. Users can perfectly call string manipulation functions passing length, or even use plain memcopy instead. SZ are just a facility. In most other languages array length is managed, it's logical that is the same for strings.


• in modern times anyway 1 byte character sets are not enough and you often have to deal with encoded unicode strings where the number of characters is very different of the number of bytes. It implies that users will probably want more than "just the size", but also other informations. Keeping length give use nothing (particularly no natural place to store them) regarding these other useful pieces of information.

That said, no need to complain in the rare case where standard C strings are indeed inefficient. Libs are available. If I followed that trend, I should complain that standard C does not include any regex support functions... but really everybody knows it's not a real problem as there is libraries available for that purpose. So when string manipulation efficiency is wanted, why not use a library like bstring ? Or even C++ strings ?

也就是说，在标准C字符串确实效率低下的极少数情况下，没有必要抱怨。LIBS可用。如果我遵循这一趋势，我应该抱怨标准C不包括任何正则表达式支持函数……但实际上，每个人都知道这不是一个真正的问题，因为有可用于该目的的库。因此，当需要高效的字符串操作时，为什么不使用像bstring这样的库呢？甚至是C++字符串？

EDIT: I recently had a look to D strings. It is interesting enough to see that the solution choosed is neither a size prefix, nor zero termination. As in C, literal strings enclosed in double quotes are just short hand for immutable char arrays, and the language also has a string keyword meaning that (immutable char array).

编辑：我最近看了一下D字符串。有趣的是，选择的解决方案既不是大小前缀，也不是零终止。与在C中一样，用双引号括起来的文字字符串只是不可变字符数组的缩写，而且该语言还有一个字符串关键字，意思是(不可变字符数组)。

But D arrays are much richer than C arrays. In the case of static arrays length is known at run-time so there is no need to store the length. Compiler has it at compile time. In the case of dynamic arrays, length is available but D documentation does not state where it is kept. For all we know, compiler could choose to keep it in some register, or in some variable stored far away from the characters data.

但D数组比C数组丰富得多。在静态数组的情况下，长度在运行时是已知的，因此不需要存储长度。编译器在编译时拥有它。在动态数组的情况下，长度是可用的，但D文档没有说明它保存在哪里。就我们所知，编译器可以选择将其保存在某个寄存器中，或者保存在远离字符数据的某个变量中。

On normal char arrays or non literal strings there is no final zero, hence programmer has to put it itself if he wants to call some C function from D. In the particular case of literal strings, however the D compiler still put a zero at the end of each strings (to allow easy cast to C strings to make easier calling C function ?), but this zero is not part of the string (D does not count it in string size).

在正常的字符数组或非文字字符串上，没有最终的零，因此程序员如果想从D调用一些C函数，就必须把它自己放进去。在文字字符串的特殊情况下，D编译器仍然在每个字符串的末尾放一个零(为了便于转换为C字符串，以便更容易地调用C函数？)，但这个零不是字符串的一部分(D不将其计入字符串大小)。

The only thing that disappointed me somewhat is that strings are supposed to be utf-8, but length apparently still returns a number of bytes (at least it's true on my compiler gdc) even when using multi-byte chars. It is unclear to me if it's a compiler bug or by purpose. (OK, I probably have found out what happened. To say to D compiler your source use utf-8 you have to put some stupid byte order mark at beginning. I write stupid because I know of not editor doing that, especially for UTF-8 that is supposed to be ASCII compatible).

唯一让我有点失望的是，字符串应该是utf-8格式，但LENGTH显然仍然返回许多字节(至少在我的编译器GDC上是这样)，即使使用多字节字符。我不清楚这是一个编译器错误还是故意的。(好的，我可能已经知道发生了什么。要告诉D编译器您的源代码使用UTF-8，您必须在开头加上一些愚蠢的字节顺序标记。我写得很愚蠢，因为我知道没有这样做的编辑器，特别是对于应该是ASCII兼容的UTF-8)。

I think, it has historical reasons and found this in wikipedia:

我认为，这是有历史原因的，并在维基百科上找到了这样的内容：

At the time C (and the languages that
it was derived from) were developed,
memory was extremely limited, so using
only one byte of overhead to store the
length of a string was attractive. The
only popular alternative at that time,
usually called a "Pascal string"
(though also used by early versions of
BASIC), used a leading byte to store
the length of the string. This allows
the string to contain NUL and made
finding the length need only one
memory access (O(1) (constant) time).
But one byte limits the length to 255.
This length limitation was far more
restrictive than the problems with the
C string, so the C string in general
won out.

Calavera is right, but as people don't seem to get his point, I'll provide some code examples.

Calvera是对的，但由于人们似乎不理解他的观点，我将提供一些代码示例。

First, let's consider what C is: a simple language, where all code has a pretty direct translation into machine language. All types fit into registers and on the stack, and it doesn't require an operating system or a big run-time library to run, since it were meant to write these things (a task to which is superbly well-suited, considering there isn't even a likely competitor to this day).

首先，让我们考虑一下C是什么：一种简单的语言，其中所有代码都可以相当直接地翻译成机器语言。所有类型都适合寄存器和堆栈，而且它不需要操作系统或大型运行时库来运行，因为它的目的是编写这些内容(考虑到目前甚至没有可能的竞争对手，这项任务非常适合)。

If C had a string type, like int or char, it would be a type which didn't fit in a register or in the stack, and would require memory allocation (with all its supporting infrastructure) to be handled in any way. All of which go against the basic tenets of C.

如果C有一个字符串类型，比如int或char，那么它就是一个不适合寄存器或堆栈的类型，并且需要以任何方式处理内存分配(及其所有支持基础设施)。所有这些都违背了C。

So, a string in C is:

因此，C中的字符串是：

char s*;

So, let's assume then that this were length-prefixed. Let's write the code to concatenate two strings:

因此，让我们假设这是长度前缀。让我们编写代码来连接两个字符串：

char* concat(char* s1, char* s2)
{
    /* What? What is the type of the length of the string? */
    int l1 = *(int*) s1;
    /* How much? How much must I skip? */
    char *s1s = s1 + sizeof(int);
    int l2 = *(int*) s2;
    char *s2s = s2 + sizeof(int);
    int l3 = l1 + l2;
    char *s3 = (char*) malloc(l3 + sizeof(int));
    char *s3s = s3 + sizeof(int);
    memcpy(s3s, s1s, l1);
    memcpy(s3s + l1, s2s, l2);
    *(int*) s3 = l3;
    return s3;
}

Another alternative would be using a struct to define a string:

另一种选择是使用结构来定义字符串：

struct {
  int len; /* cannot be left implementation-defined */
  char* buf;
}

At this point, all string manipulation would require two allocations to be made, which, in practice, means you'd go through a library to do any handling of it.

在这一点上，所有的字符串操作都需要进行两次分配，这实际上意味着您需要遍历一个库来处理它。

The funny thing is... structs like that do exist in C! They are just not used for your day-to-day displaying messages to the user handling.

有趣的是..。这样的结构确实存在于C中！它们只是不用于您向用户处理的日常显示消息。

So, here is the point Calavera is making: there is no string type in C. To do anything with it, you'd have to take a pointer and decode it as a pointer to two different types, and then it becomes very relevant what is the size of a string, and cannot just be left as "implementation defined".

所以，这就是卡拉维拉的观点：在C中没有字符串类型，要对它做任何事情，你必须获得一个指针，并将其解码为指向两个不同类型的指针，然后它就变得非常相关，字符串的大小是什么，不能只是“实现定义的”。

Now, C can handle memory in anyway, and the mem functions in the library (in <string.h>, even!) provide all the tooling you need to handle memory as a pair of pointer and size. The so-called "strings" in C were created for just one purpose: showing messages in the context of writting an operating system intended for text terminals. And, for that, null termination is enough.

现在，C语言可以以任何方式处理内存，库中的mem函数(甚至在 中！)提供将内存作为一对指针和大小进行处理所需的所有工具。在C中创建所谓的“字符串”只有一个目的：在编写用于文本终端的操作系统的上下文中显示消息。为此，零终止就足够了。

Obviously for performance and safety, you'll want to keep the length of a string while you're working with it rather than repeatedly performing strlen or the equivalent on it. However, storing the length in a fixed location just before the string contents is an incredibly bad design. As Jörgen pointed out in the comments on Sanjit's answer, it precludes treating the tail of a string as a string, which for example makes a lot of common operations like path_to_filename or filename_to_extension impossible without allocating new memory (and incurring the possibility of failure and error handling). And then of course there's the issue that nobody can agree how many bytes the string length field should occupy (plenty of bad "Pascal string" languages used 16-bit fields or even 24-bit fields which preclude processing of long strings).

显然，出于性能和安全考虑，您需要在处理字符串时保持该字符串的长度，而不是重复对其执行strlen或等效值。然而，将长度存储在字符串内容之前的固定位置是一个令人难以置信的糟糕设计。正如Jörgen在对Sanjit的回答的评论中指出的那样，它排除了将字符串的尾部视为字符串的可能性，例如，这使得许多常见的操作，如路径到文件名或文件名到扩展名，在不分配新内存的情况下是不可能的(并且会招致失败和错误处理的可能性)。当然，还有一个问题是，没有人能就字符串长度字段应该占用多少字节达成一致(许多糟糕的“Pascal字符串”语言使用16位字段，甚至24位字段，这排除了对长字符串的处理)。

C's design of letting the programmer choose if/where/how to store the length is much more flexible and powerful. But of course the programmer has to be smart. C punishes stupidity with programs that crash, grind to a halt, or give your enemies root.

C的设计允许程序员选择是否/在哪里/如何存储长度，这要灵活得多，功能也更强大。但当然，程序员必须是聪明的。C用来惩罚愚蠢的程序，这些程序会崩溃、陷入停顿，或者让你的敌人扎根。

Lazyness, register frugality and portability considering the assembly gut of any language, especially C which is one step above assembly (thus inheriting a lot of assembly legacy code).
You would agree as a null char would be useless in those ASCII days, it (and probably as good as an EOF control char ).

懒惰，注册节俭和可移植性考虑到任何语言的汇编语言，特别是C语言，它比汇编语言高一步(因此继承了许多汇编语言遗留代码)。你会同意，因为空字符在那些ASCII时代是毫无用处的，它(可能和EOF控制字符一样好)。

let's see in pseudo code

让我们看一下伪代码

function readString(string) // 1 parameter: 1 register or 1 stact entries
    pointer=addressOf(string) 
    while(string[pointer]!=CONTROL_CHAR) do
        read(string[pointer])
        increment pointer

total 1 register use

共使用1个寄存器

case 2

壳体2

 function readString(length,string) // 2 parameters: 2 register used or 2 stack entries
     pointer=addressOf(string) 
     while(length>0) do 
         read(string[pointer])
         increment pointer
         decrement length

total 2 register used

共使用2个寄存器

That might seem shortsighted at that time, but considering the frugality in code and register ( which were PREMIUM at that time, the time when you know, they use punch card ). Thus being faster ( when processor speed could be counted in kHz), this "Hack" was pretty darn good and portable to register-less processor with ease.

这在当时可能看起来很短视，但考虑到在代码和寄存器方面的节俭(这在当时是溢价的，你知道，他们使用穿孔卡片)。因此，由于速度更快(当处理器速度可以用khz计算时)，这个“Hack”非常好，并且可以很容易地移植到无注册处理器。

For argument sake I will implement 2 common string operation

为了便于讨论，我将实现2个常见的字符串操作

stringLength(string)
     pointer=addressOf(string)
     while(string[pointer]!=CONTROL_CHAR) do
         increment pointer
     return pointer-addressOf(string)

complexity O(n) where in most case PASCAL string is O(1) because the length of the string is pre-pended to the string structure (that would also mean that this operation would have to be carried in an earlier stage).

复杂性O(N)，其中在大多数情况下Pascal字符串是O(1)，因为字符串的长度是字符串结构的前缀(这也意味着必须在更早的阶段执行该操作)。

concatString(string1,string2)
     length1=stringLength(string1)
     length2=stringLength(string2)
     string3=allocate(string1+string2)
     pointer1=addressOf(string1)
     pointer3=addressOf(string3)
     while(string1[pointer1]!=CONTROL_CHAR) do
         string3[pointer3]=string1[pointer1]
         increment pointer3
         increment pointer1
     pointer2=addressOf(string2)
     while(string2[pointer2]!=CONTROL_CHAR) do
         string3[pointer3]=string2[pointer2]
         increment pointer3
         increment pointer1
     return string3

complexity O(n) and prepending the string length wouldn't change the complexity of the operation, while I admit it would take 3 time less time.

复杂性O(N)和前缀字符串长度不会改变操作的复杂性，虽然我承认这会减少3倍的时间。

On another hand, if you use PASCAL string you would have to redesign your API for taking in account register length and bit-endianness, PASCAL string got the well known limitation of 255 char (0xFF) beacause the length was stored in 1 byte (8bits), and it you wanted a longer string (16bits->anything) you would have to take in account the architecture in one layer of your code, that would mean in most case incompatible string APIs if you wanted longer string.

另一方面，如果你使用Pascal字符串，你将不得不重新设计你的API来考虑寄存器长度和位字符顺序，Pascal字符串得到了众所周知的255字符(0xFF)的限制，因为长度是以1字节(8位)存储的，如果你想要更长的字符串(16位->任何东西)，你必须考虑代码的一层中的体系结构，这意味着在大多数情况下，如果你想要更长的字符串，那将意味着不兼容的字符串API。

Example:

示例：

One file was written with your prepended string api on an 8 bit computer and then would have to be read on say a 32 bit computer, what would the lazy program do considers that your 4bytes are the length of the string then allocate that lot of memory then attempt to read that many bytes.
Another case would be PPC 32 byte string read(little endian) onto a x86 (big endian), of course if you don't know that one is written by the other there would be trouble.
1 byte length (0x00000001) would become 16777216 (0x0100000) that is 16 MB for reading a 1 byte string.
Of course you would say that people should agree on one standard but even 16bit unicode got little and big endianness.

一个文件是在8位计算机上用您预先考虑的字符串API编写的，然后必须在32位计算机上读取，如果您的4个字节是字符串的长度，那么懒惰程序会做什么，然后分配大量内存，然后尝试读取那么多字节。另一种情况是将PPC 32字节字符串读取(小端)到x86(大端)，当然，如果您不知道其中一个是由另一个写入的，就会有麻烦。1字节长度(0x00000001)将变为16777216(0x0100000)，即读取1字节字符串的16MB。当然，你会说人们应该在一种标准上达成一致，但即使是16位Unicode也得到了越来越大的字节顺序。

Of course C would have its issues too but, would be very little affected by the issues raised here.

当然，C也会有它的问题，但不会受到这里提出的问题的影响。

In many ways, C was primitive. And I loved it.

在很多方面，C语言都是原始的。我爱死它了。

It was a step above assembly language, giving you nearly the same performance with a language that was much easier to write and maintain.

它比汇编语言更胜一筹，用一种更容易编写和维护的语言提供了几乎相同的性能。

The null terminator is simple and requires no special support by the language.

空终止符很简单，不需要语言的特殊支持。

Looking back, it doesn't seem that convenient. But I used assembly language back in the 80s and it seemed very convenient at the time. I just think software is continually evolving, and the platforms and tools continually get more and more sophisticated.

回首往事，这似乎并不那么方便。但我在80年代用的是汇编语言，当时看起来很方便。我只是认为软件在不断发展，平台和工具也在不断地变得越来越复杂。

Assuming for a moment that C implemented strings the Pascal way, by prefixing them by length: is a 7 char long string the same DATA TYPE as a 3-char string? If the answer is yes, then what kind of code should the compiler generate when I assign the former to the latter? Should the string be truncated, or automatically resized? If resized, should that operation be protected by a lock as to make it thread safe? The C approach side stepped all these issues, like it or not :)

假设C以Pascal的方式实现字符串，在字符串前面加上长度：7个字符的字符串是否与3个字符的字符串的数据类型相同？如果答案是肯定的，那么当我将前者赋给后者时，编译器应该生成什么样的代码？字符串应该被截断，还是应该自动调整大小？如果调整大小，是否应该使用锁保护该操作以使其线程安全？C方法方面回避了所有这些问题，不管你喜不喜欢：)

Somehow I understood the question to imply there's no compiler support for length-prefixed strings in C. The following example shows, at least you can start your own C string library, where string lengths are counted at compile time, with a construct like this:

不知何故，我理解了这个问题的意思是，C中不存在对长度前缀字符串的编译器支持。下面的示例显示，至少您可以使用如下结构启动您自己的C字符串库，其中字符串长度在编译时计算：

#define PREFIX_STR(s) ((prefix_str_t){ sizeof(s)-1, (s) })

typedef struct { int n; char * p; } prefix_str_t;

int main() {
    prefix_str_t string1, string2;

    string1 = PREFIX_STR("Hello!");
    string2 = PREFIX_STR("Allows \0 chars (even if printf directly doesn't)");

    printf("%d %s\n", string1.n, string1.p); /* prints: "6 Hello!" */
    printf("%d %s\n", string2.n, string2.p); /* prints: "48 Allows " */

    return 0;
}

This won't, however, come with no issues as you need to be careful when to specifically free that string pointer and when it is statically allocated (literal char array).

然而，这不会带来任何问题，因为您需要特别注意何时释放字符串指针以及何时静态分配它(文字字符数组)。

Edit: As a more direct answer to the question, my view is this was the way C could support both having string length available (as a compile time constant), should you need it, but still with no memory overhead if you want to use only pointers and zero termination.

编辑：作为对这个问题的一个更直接的回答，我的观点是，这是C可以支持的方式，既有可用的字符串长度(作为编译时间常量)，如果您需要的话，但如果您只想使用指针和零终止，仍然没有内存开销。

Of course it seems like working with zero-terminated strings was the recommended practice, since the standard library in general doesn't take string lengths as arguments, and since extracting the length isn't as straightforward code as char * s = "abc", as my example shows.

当然，使用以零结尾的字符串似乎是推荐的做法，因为标准库通常不接受字符串长度作为参数，而且提取长度不像char*S=“abc”那样简单，如我的示例所示。

"Even on a 32 bit machine, if you allow the string to be the size of available memory, a length prefixed string is only three bytes wider than a null terminated string."

First, extra 3 bytes may be considerable overhead for short strings. In particular, a zero-length string now takes 4 times as much memory. Some of us are using 64-bit machines, so we either need 8 bytes to store a zero-length string, or the string format can't cope with the longest strings the platform supports.

首先，对于短字符串来说，额外的3个字节可能是相当大的开销。特别是，零长度字符串现在占用的内存是原来的4倍。我们中的一些人使用的是64位机器，因此我们要么需要8个字节来存储零长度的字符串，要么字符串格式无法处理平台支持的最长字符串。

There may also be alignment issues to deal with. Suppose I have a block of memory containing 7 strings, like "solo\0second\0\0four\0five\0\0seventh". The second string starts at offset 5. The hardware may require that 32-bit integers be aligned at an address that is a multiple of 4, so you have to add padding, increasing the overhead even further. The C representation is very memory-efficient in comparison. (Memory-efficiency is good; it helps cache performance, for example.)

可能还需要处理调整问题。假设我有一个包含7个字符串的内存块，比如“solo\0Second\0\0four\0Five\0\077.”。第二个字符串从偏移量5开始。硬件可能要求32位整数在是4的倍数的地址对齐，因此您必须添加填充，这会进一步增加开销。相比之下，C表示非常节省内存。(内存效率很好；例如，它有助于提高缓存性能。)

One point not yet mentioned: when C was designed, there were many machines where a 'char' was not eight bits (even today there are DSP platforms where it isn't). If one decides that strings are to be length-prefixed, how many 'char's worth of length prefix should one use? Using two would impose an artificial limit on string length for machines with 8-bit char and 32-bit addressing space, while wasting space on machines with 16-bit char and 16-bit addressing space.

有一点还没有提到：在设计C语言的时候，有许多机器的‘char’不是8位(即使在今天，也有不是8位的DSP平台)。如果决定将字符串作为长度前缀，那么应该使用多少个字符的长度前缀？使用两个字符将对具有8位字符和32位寻址空间的计算机的字符串长度施加人为限制，而浪费具有16位字符和16位寻址空间的计算机的空间。

If one wanted to allow arbitrary-length strings to be stored efficiently, and if 'char' were always 8-bits, one could--for some expense in speed and code size--define a scheme were a string prefixed by an even number N would be N/2 bytes long, a string prefixed by an odd value N and an even value M (reading backward) could be ((N-1) + M*char_max)/2, etc. and require that any buffer which claims to offer a certain amount of space to hold a string must allow enough bytes preceding that space to handle the maximum length. The fact that 'char' isn't always 8 bits, however, would complicate such a scheme, since the number of 'char' required to hold a string's length would vary depending upon the CPU architecture.

如果人们想要允许有效地存储任意长度的字符串，并且如果‘char’总是8位，那么可以定义一种方案，即以偶数N为前缀的字符串将是N/2字节长，以奇数N和偶数值M为前缀的字符串可以是((N-1)+M*char_max)/2等等，并且要求任何声称提供一定量的空间来容纳字符串的缓冲区必须在该空间之前允许足够的字节来处理最大长度。然而，“char”并非总是8位的事实会使这种方案变得复杂，因为保存字符串长度所需的“char”数量会因CPU体系结构而异。

The null termination allows for fast pointer based operations.

空终止允许基于指针的快速操作。

Not a Rationale necessarily but a counterpoint to length-encoded

不一定是长度编码的基本原理，而是长度编码的对立面

1. Certain forms of dynamic length encoding are superior to static length encoding as far as memory is concerned, it all depends on usage. Just look at UTF-8 for proof. It's essentially an extensible character array for encoding a single character. This uses a single bit for each extended byte. NUL termination uses 8 bits. Length-prefix I think can be reasonably termed infinite length as well by using 64 bits. How often you hit the case of your extra bits is the deciding factor. Only 1 extremely large string? Who cares if you're using 8 or 64 bits? Many small strings (Ie Strings of English words)? Then your prefix costs are a large percentage.




2. Length-prefixed strings allowing time savings is not a real thing. Whether your supplied data is required to have length provided, you're counting at compile time, or you're truly being provided dynamic data that you must encode as a string. These sizes are computed at some point in the algorithm. A separate variable to store the size of a null terminated string can be provided. Which makes the comparison on time-savings moot. One just has an extra NUL at the end... but if the length encode doesn't include that NUL then there's literally no difference between the two. There's no algorithmic change required at all. Just a pre-pass you have to manually design yourself instead of having a compiler/runtime do it for you. C is mostly about doing things manually.




3. Length-prefix being optional is a selling point. I don't always need that extra info for an algorithm so being required to do it for a every string makes my precompute+compute time never able to drop below O(n). (Ie hardware random number generator 1-128. I can pull from an "infinite string". Let's say it only generates characters so fast. So our string length changes all the time. But my usage of the data probably doesn't care how many random bytes I have. It just wants the next available unused byte as soon as it can get it after a request. I could be waiting on the device. But I could also have a buffer of characters pre-read. A length comparison is a needless waste of computation. A null check is more efficient.)




4. Length-prefix is a good guard against buffer overflow? So is sane usage of library functions and implementation. What if I pass in malformed data? My buffer is 2 bytes long but I tell the function it's 7! Ex: If gets() was intended to be used on known data it could've had an internal buffer check that tested compiled buffers and malloc() calls and still follow spec. If it was meant to be used as a pipe for unknown STDIN to arrive at unknown buffer then clearly one can't know abut the buffer size which means a length arg is pointless, you need something else here like a canary check. For that matter, you can't length-prefix some streams and inputs, you just can't. Which means the length check has to be built into the algorithm and not a magic part of the typing system. TL;DR NUL-terminated never had to be unsafe, it just ended up that way via misuse.




5. counter-counter point: NUL-termination is annoying on binary. You either need to do length-prefix here or transform NUL bytes in some way: escape-codes, range remapping, etc... which of course means more-memory-usage/reduced-information/more-operations-per-byte. Length-prefix mostly wins the war here. The only upside to a transform is that no additional functions have to be written to cover the length-prefix strings. Which means on your more optimized sub-O(n) routines you can have them automatically act as their O(n) equivalents without adding more code. Downside is, of course, time/memory/compression waste when used on NUL heavy strings. Depending on how much of your library you end up duplicating to operate on binary data, it may make sense to work solely with length-prefix strings. That said one could also do the same with length-prefix strings... -1 length could mean NUL-terminated and you could use NUL-terminated strings inside length-terminated.




6. Concat: "O(n+m) vs O(m)" I'm assuming your referring to m as the total length of the string after concatenating because they both have to have that number of operations minimum (you can't just tack-on to string 1, what if you have to realloc?). And I'm assuming n is a mythical amount of operations you no longer have to do because of a pre-compute. If so, then the answer is simple: pre-compute. If you're insisting you'll always have enough memory to not need to realloc and that's the basis of the big-O notation then the answer is even more simple: do binary search on allocated memory for end of string 1, clearly there's a large swatch of infinite zeros after string 1 for us to not worry about realloc. There, easily got n to log(n) and I barely tried. Which if you recall log(n) is essentially only ever as large as 64 on a real computer, which is essentially like saying O(64+m), which is essentially O(m). (And yes that logic has been used in run-time analysis of real data structures in-use today. It's not bullshit off the top of my head.)




7. Concat()/Len() _again: Memoize results. Easy. Turns all computes into pre-computes if possible/necessary. This is an algorithmic decision. It's not an enforced constraint of the language.




8. String suffix passing is easier/possible with NUL termination. Depending on how length-prefix is implemented it can be destructive on original string and can sometimes not even be possible. Requiring a copy and pass O(n) instead of O(1).




9. Argument-passing/de-referencing is less for NUL-terminated versus length-prefix. Obviously because you're passing less information. If you don't need length, then this saves a lot of footprint and allows optimizations.




10. You can cheat. It's really just a pointer. Who says you have to read it as a string? What if you want to read it as a single character or a float? What if you want to do the opposite and read a float as a string? If you're careful you can do this with NUL-termination. You can't do this with length-prefix, it's a data type distinctly different from a pointer typically. You'd most likely have to build a string byte-by-byte and get the length. Of course if you wanted something like an entire float (probably has a NUL inside it) you'd have to read byte-by-byte anyway, but the details are left to you to decide.

TL;DR Are you using binary data? If no, then NUL-termination allows more algorithmic freedom. If yes, then code quantity vs speed/memory/compression is your main concern. A blend of the two approaches or memoization might be best.

TL；DR您使用的是二进制数据吗？如果不是，则NUL终止允许更多的算法自由。如果是，则代码量与速度/内存/压缩是您主要关心的问题。将这两种方法结合起来，或者是备忘录，可能是最好的选择。

Many design decisions surrounding C stem from the fact that when it was originally implemented, parameter passing was somewhat expensive. Given a choice between e.g.

许多围绕C语言的设计决策源于这样一个事实，即最初实现它时，传递参数的成本有点高。如果要在以下选项中进行选择，例如

void add_element_to_next(arr, offset)
  char[] arr;
  int offset;
{
  arr[offset] += arr[offset+1];
}

char array[40];

void test()
{
  for (i=0; i<39; i++)
    add_element_to_next(array, i);
}

versus

与

void add_element_to_next(ptr)
  char *p;
{
  p[0]+=p[1];
}

char array[40];

void test()
{
  int i;
  for (i=0; i<39; i++)
    add_element_to_next(arr+i);
}

the latter would have been slightly cheaper (and thus preferred) since it only required passing one parameter rather than two. If the method being called didn't need to know the base address of the array nor the index within it, passing a single pointer combining the two would be cheaper than passing the values separately.

后者会稍微便宜一些(因此更受欢迎)，因为它只需要传递一个参数，而不是两个。如果被调用的方法既不需要知道数组的基地址，也不需要知道数组中的索引，那么传递一个组合了两者的单个指针比单独传递两个值要便宜。

While there are many reasonable ways in which C could have encoded string lengths, the approaches that had been invented up to that time would have all required functions that should be able to work with part of a string to accept the base address of the string and the desired index as two separate parameters. Using zero-byte termination made it possible to avoid that requirement. Although other approaches would be better with today's machines (modern compilers often pass parameters in registers, and memcpy can be optimized in ways strcpy()-equivalents cannot) enough production code uses zero-byte terminated strings that it's hard to change to anything else.

虽然有许多合理的方法可以让C对字符串长度进行编码，但到那时为止已经发明的方法都需要能够处理字符串的一部分的函数来接受字符串的基地址和所需的索引作为两个单独的参数。使用零字节终止使避免这一要求成为可能。尽管其他方法在当今的机器上会更好(现代编译器通常在寄存器中传递参数，并且可以通过strcpy()等效项无法实现的方式对memcpy进行优化)，但是足够多的生产代码使用以零字节结尾的字符串，因此很难更改为其他任何字符串。

PS--In exchange for a slight speed penalty on some operations, and a tiny bit of extra overhead on longer strings, it would have been possible to have methods that work with strings accept pointers directly to strings, bounds-checked string buffers, or data structures identifying substrings of another string. A function like "strcat" would have looked something like [modern syntax]

PS--为了换取一些操作的轻微速度损失和较长字符串的少量额外开销，可以让处理字符串的方法直接接受指向字符串、边界检查的字符串缓冲区或标识另一个字符串的子字符串的数据结构的指针。像“strcat”这样的函数应该类似于[现代语法]

void strcat(unsigned char *dest, unsigned char *src)
{
  struct STRING_INFO d,s;
  str_size_t copy_length;

  get_string_info(&d, dest);
  get_string_info(&s, src);
  if (d.si_buff_size > d.si_length) // Destination is resizable buffer
  {
    copy_length = d.si_buff_size - d.si_length;
    if (s.src_length < copy_length)
      copy_length = s.src_length;
    memcpy(d.buff + d.si_length, s.buff, copy_length);
    d.si_length += copy_length;
    update_string_length(&d);
  }
}

A little bigger than the K&R strcat method, but it would support bounds-checking, which the K&R method doesn't. Further, unlike the current method, it would be possible to easily concatenate an arbitrary substring, e.g.

比K&R strcat方法稍大一些，但它将支持边界检查，而K&R方法不支持边界检查。

/* Concatenate 10th through 24th characters from src to dest */

void catpart(unsigned char *dest, unsigned char *src)
{
  struct SUBSTRING_INFO *inf;
  src = temp_substring(&inf, src, 10, 24);
  strcat(dest, src);
}

Note that the lifetime of the string returned by temp_substring would be limited by those of s and src, which ever was shorter (which is why the method requires inf to be passed in--if it was local, it would die when the method returned).

请注意，TEMP_SUBSTRING返回的字符串的生存期将受到S和src的生存期的限制，这两个字符串的生存期更短(这就是该方法要求传入inf的原因--如果它是本地的，那么它将在方法返回时终止)。

In terms of memory cost, strings and buffers up to 64 bytes would have one byte of overhead (same as zero-terminated strings); longer strings would have slightly more (whether one allowed amounts of overhead between two bytes and the maximum required would be a time/space tradeoff). A special value of the length/mode byte would be used to indicate that a string function was given a structure containing a flag byte, a pointer, and a buffer length (which could then index arbitrarily into any other string).

在内存成本方面，最多64个字节的字符串和缓冲区将有一个字节的开销(与以零结尾的字符串相同)；较长的字符串将有稍微多一点的开销(是否允许两个字节之间的开销量和所需的最大值将是时间/空间的权衡)。长度/模式字节的特定值将被用来指示字符串函数被赋予了包含标志字节、指针和缓冲区长度(然后可以任意索引到任何其他字符串)的结构。

Of course, K&R didn't implement any such thing, but that's most likely because they didn't want to spend much effort on string handling--an area where even today many languages seem rather anemic.

当然，K&R没有实现任何这样的东西，但这很可能是因为他们不想在字符串处理上花费太多精力--即使在今天，许多语言似乎仍然相当贫乏。

According to Joel Spolsky in this blog post,

根据乔尔·斯波尔斯基在这篇博客文章中的说法，

It's because the PDP-7 microprocessor, on which UNIX and the C programming language were invented, had an ASCIZ string type. ASCIZ meant "ASCII with a Z (zero) at the end."

After seeing all the other answers here, I'm convinced that even if this is true, it's only part of the reason for C having null-terminated "strings". That post is quite illuminating as to how simple things like strings can actually be quite hard.

在看到这里的所有其他答案后，我确信即使这是真的，这也只是C具有以空结尾的“字符串”的部分原因。这篇文章很有启发性，说明像字符串这样简单的事情实际上可能相当困难。

I don't buy the "C has no string" answer. True, C does not support built-in higher-level types but you can still represent data-structures in C and that's what a string is. The fact a string is just a pointer in C does not mean the first N bytes cannot take on special meaning as a the length.

我不买“C没有字符串”的答案。的确，C不支持内置的高级类型，但你仍然可以在C中表示数据结构，这就是字符串。事实上，字符串在C中只是一个指针，并不意味着前N个字节不能作为长度具有特殊意义。

Windows/COM developers will be very familiar with the BSTR type which is exactly like this - a length-prefixed C string where the actual character data starts not at byte 0.

Windows/COM开发人员将非常熟悉BSTR类型，它就像这样-一个长度前缀的C字符串，其中实际的字符数据不是从字节0开始。

So it seems that the decision to use null-termination is simply what people preferred, not a necessity of the language.

因此，使用零结尾的决定似乎是人们更喜欢的，而不是语言的必然。

One advantage of NUL-termination over length-prefixing, which I have not seen anyone mention, is the simplicity of string comparison. Consider the comparison standard which returns a signed result for less-than, equal, or greater-than. For length-prefixing the algorithm has to be something along the following lines:

与长度前缀相比，NUL结尾的一个优点是字符串比较简单，我还没有见过任何人提到这一点。考虑一下比较标准，它返回小于、等于或大于的带符号结果。对于长度前缀，算法必须遵循以下路线：

1. Compare the two lengths; record the smaller, and note if they are equal (this last step might be deferred to step 3).


2. Scan the two character sequences, subtracting characters at matching indices (or use a dual pointer scan). Stop either when the difference is nonzero, returning the difference, or when the number of characters scanned is equal to the smaller length.


3. When the smaller length is reached, one string is a prefix of the other. Return negative or positive value according to which is shorter, or zero if of equal length.

Contrast this with the NUL-termination algorithm:

将其与NUL终止算法进行对比：

1. Scan the two character sequences, subtracting characters at matching indices [note that this is handled better with moving pointers]. Stop when the difference is nonzero, returning the difference. NOTE: If one string is a PROPER prefix of the other, one of the characters in the subtraction will be NUL, i.e zero, and the comparison will naturally stop there.


2. If the difference is zero, -only then- check if either character is NUL. If so, return zero, otherwise continue to next character.

The NUL-terminated case is simpler, and very easy to implement efficiently with a dual pointer scan. The length-prefixed case does at least as much work, nearly always more. If your algorithm has to do a lot of string comparisons [e.g a compiler!], the NUL-terminated case wins out. Nowadays that might not be as important, but back in the day, heck yeah.

NUL终止的情况更简单，并且使用双指针扫描非常容易有效地实现。带长度前缀的大小写至少执行同样多的工作，几乎总是更多。如果您的算法必须进行大量的字符串比较[例如，编译器！]，则以NUL结尾的情况会胜出。如今，这可能不那么重要，但在过去，见鬼，是的。

gcc accept the codes below:

GCC接受以下代码：

char s[4] = "abcd";

字符S[4]=“abcd”；

and it's ok if we treat is as an array of chars but not string. That is, we can access it with s[0], s[1], s[2], and s[3], or even with memcpy(dest, s, 4). But we'll get messy characters when we trying with puts(s), or worse with strcpy(dest, s).

如果我们将is视为字符数组，而不是字符串，这是可以接受的。也就是说，我们可以使用S[0]、S[1]、S[2]和S[3]访问它，甚至可以使用Memcpy(DEST、S，4)访问它。但当我们尝试推杆(S)时，我们会得到乱七八糟的字符，或者更糟糕的是，用斯特西(最好的，S)。

I think the better question is why you think C owes you anything? C was designed to give you what you need, nothing more. You need to loose the mentality that the language must provide you with everything. Or just continue to use your higher level languages that will give you the luxary of String, Calendar, Containers; and in the case of Java you get one thing in tonnes of variety. Multiple types String, multiple types of unordered_map(s).

我觉得更好的问题是为什么你认为C欠你什么？C是为了满足您的需求而设计的，仅此而已。你需要放松这样一种心态，即语言必须为你提供一切。或者继续使用您的高级语言，让您拥有丰富的字符串、日历和容器；在Java中，您可以获得千变万化的东西。多类型字符串，多类型无序_图(S)。

Too bad for you, this was not the purpose of C. C was not designed to be a bloated language that offers from a pin to an anchor. Instead you must rely on third party libraries or your own. And there is nothing easier than creating a simple struct that will contain a string and its size.

对你来说太糟糕了，这不是C语言的目的，C语言不是被设计成一种提供从大头针到锚的臃肿语言。相反，您必须依赖第三方库或您自己的库。没有什么比创建一个包含字符串及其大小的简单结构更容易的了。

struct String
{
 const char *s;
 size_t len;
};

You know what the problem is with this though. It is not standard. Another language might decide to organize the len before the string. Another language might decide to use a pointer to end instead. Another might decide to use six pointers to make the String more efficient. However a null terminated string is the most standard format for a string; which you can use to interface with any language. Even Java JNI uses null terminated strings.

不过，你知道这有什么问题。这不是标准的。另一种语言可能决定在字符串之前组织镜头。另一种语言可能决定使用指针作为结尾。另一个可能决定使用六个指针来提高字符串的效率。但是，以空结尾的字符串是最标准的字符串格式；您可以使用这种格式与任何语言交互。即使是Java JNI也使用以空结尾的字符串。

Lastly, it is a common saying; the right data structure for the task. If you find that need to know the size of a string more than anything else; well use a string structure that allows you to do that optimally. But don't make claims that that operation is used more than anything else for everybody. Like, why is knowing the size of a string more important than reading its contents. I find that reading the contents of a string is what I mostly do, so I use null terminated strings instead of std::string; which saves me 5 pointers on a GCC compiler. If I can even save 2 pointers that is good.

最后，这是一种常见的说法；任务的正确数据结构。如果您发现最需要知道字符串的大小，那么我们将使用允许您以最佳方式完成此任务的字符串结构。但不要声称，对每个人来说，这个手术比其他任何东西都更重要。比如，为什么知道字符串的大小比读取其内容更重要。我发现我主要做的就是读取字符串的内容，所以我使用以空结尾的字符串而不是std：：String；这为我在GCC编译器上节省了5个指针。如果我能保住2分，那就太好了。