我觉得更好的问题是你为什么觉得C欠你什么?C语言的设计是为了满足你的需要，仅此而已。你需要摆脱那种认为语言必须为你提供一切的心态。或者只是继续使用你的高级语言，这将给你奢侈的字符串，日历，容器;而在Java中，你会得到一种千变万化的东西。多个类型字符串，多个类型的unordered_map(s)。

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

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

你知道问题出在哪里。它不标准。另一种语言可能决定将len组织在字符串之前。另一种语言可能决定使用指针来代替结束。另一个人可能决定使用六个指针来提高String的效率。然而，null结尾的字符串是字符串的最标准格式;你可以用它来与任何语言进行交互。甚至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.

来自马的口

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, C语言的开发

在很多方面，C语言是原始的。我很喜欢。

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

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

现在回想起来，似乎并不是那么方便。但我在80年代使用汇编语言，当时它似乎非常方便。我只是认为软件在不断地发展，平台和工具也在不断地变得越来越复杂。

即使在32位机器上，如果允许字符串的大小与可用内存相同，带前缀的长度字符串也只比以空结尾的字符串宽3个字节。

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

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

我觉得更好的问题是你为什么觉得C欠你什么?C语言的设计是为了满足你的需要，仅此而已。你需要摆脱那种认为语言必须为你提供一切的心态。或者只是继续使用你的高级语言，这将给你奢侈的字符串，日历，容器;而在Java中，你会得到一种千变万化的东西。多个类型字符串，多个类型的unordered_map(s)。

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

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

你知道问题出在哪里。它不标准。另一种语言可能决定将len组织在字符串之前。另一种语言可能决定使用指针来代替结束。另一个人可能决定使用六个指针来提高String的效率。然而，null结尾的字符串是字符串的最标准格式;你可以用它来与任何语言进行交互。甚至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.

我认为，这是有历史原因的，我在维基百科上找到了这个:

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.