从编译器的角度来看，字符串是怎样的？答案

【问题标题】：How do strings look from the compiler's point of view?从编译器的角度来看，字符串是怎样的？
【发布时间】：2016-01-01 09:48:15
【问题描述】：

在C 中，编译器有一个指向字符串开头的指针和一个结束符号（'\0'）。如果用户想要计算字符串的长度，编译器必须对字符串数组的元素进行计数，直到找到'\0'。

在UCSD-strings中，编译器在第一个符号中有字符串的长度。

编译器对C#-strings 有什么看法？是的，从用户的角度来看String 是一个object，它有一个字段Length，我不是在谈论高级别的东西。我想知道深度算法；例如，编译器如何计算字符串的长度？

【问题讨论】：

你的 C 假设是错误的。 C 编译器确切地知道每个字符串有多长。要看到这一点，请在字符串上调用sizeof（而不是在指向字符串的指针上！）。
通常情况下，我会将其作为骗子关闭，但重复项很糟糕。 codeproject.com/Articles/3377/Strings-UNDOCUMENTED
@MSalters：我认为 homk 是指长度（C 中的strlen）函数的实现，而不是编译器。
您混淆了编译器看到的内容和执行时发生的情况。编译器处理字符串的方式可能与 strlen 等函数处理字符串的方式没有相似之处，编译时和运行时的表示可能完全不同。
"在 С 中，编译器有一个指向字符串开头的指针和一个结束符号 ('\0')"。不。在 C 中，编译器有一个开始引号和一个结束引号。它将以sizeof 结果的形式提供介于两者之间的字符数，无论它们是什么，包括嵌入的空值。 strlen() 与它无关，指针也无关。编译器还将在编译后的字符串中放置一个尾随空值。它不在源文本中。

标签： c# .net string memory compiler-construction

【解决方案1】：

在 C# 中，字符串的长度存储在对象的私有字段 ([NonSerialized]private int m_stringLength;) 中，不必在运行时计算。

The source code of String class is available online.

【讨论】：

【解决方案2】：

让我们执行以下代码：

string s = "123";
string s2 = "234";
string s3 = s + s2;
string s4 = s2 + s3;
Console.WriteLine(s + s2);

现在让我们在最后一行下一个断点并打开内存窗口：

在内存窗口中写入s3，我们可以看到2个（s3和s4）字符串一个接一个地分配，开头有4个字节大小。

您还可以看到分配了其他内存，例如strings 类类型标记和其他string 类数据。

string class 本身包含一个成员private int m_stringLength;，其中包含string 的长度，这也使得string.Concat() 执行速度超快（通过在开头分配整个长度）：

int totalLength = str0.Length + str1.Length + str2.Length;

String result = FastAllocateString(totalLength);
FillStringChecked(result, 0, str0);
FillStringChecked(result, str0.Length, str1);
FillStringChecked(result, str0.Length + str1.Length, str2);

我觉得有点奇怪的是，IEnumerable<char>.Count() 的 string 的实现是使用默认实现完成的，这意味着与 ICollection<T>s 不同的是，像 List<T> 这样实现了 IEnumerable<char>.Count()通过获取其ICollection<T>.Count 属性。

【讨论】：

@homk 如果这是您想知道的，那么您真正的问题与“从编译器的角度”无关。