为什么 C 中变量以随机值开始
我认为这是错误的，它应该以 NULL 开头，而不是随机值。如果您有一个以随机内存地址作为默认值的指针，那么这可能是一件非常危险的事情，不是吗？
I think this is wrong, it should start as NULL and not with a random value. In the case that you have a pointer with a random memory address as its default value it could be a very dangerous thing, no?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
变量一开始未初始化，因为这是最快的方法 - 如果您无论如何都要在那里写入另一个值，为什么要在初始化上浪费 CPU 周期呢？
如果您希望变量在创建后进行初始化，只需对其进行初始化即可。 :)
关于这是一件危险的事情：如果您尝试在没有初始化的情况下使用变量，每个好的编译器都会警告您。
The variables start out uninitialized because that's the fastest way - why waste the CPU cycles on initialization if you're going to write another value there anyway?
If you want a variable to be initialized after creation, just initialize it. :)
About it being a dangerous thing: Every good compiler will warn you if you try to use a variable without initialization.
不会。C 是一种非常高效的语言，传统上它比许多其他语言都要快。原因之一是它本身并没有做太多事情。程序员控制这个。
在初始化的情况下，C 变量不会被初始化为随机值。相反，它们没有被初始化，因此它们包含之前内存位置的任何内容。
如果您想在程序中将变量初始化为 1，那么如果该变量已经初始化为 0 或 null，则效率会很低。这意味着它被初始化了两次。
No. C is a very efficient language, one that has traditionally been faster that a lot of other languages. One of the reasons for this is that it doesn't do too much on it's own. The programmer controls this.
In the case of initialization, C variables are not initialized to a random value. Rather, they are not initialized and so they contain whatever was at the memory location before.
If you wanted to initialize a variable to, say, 1 in your program, then it would be inefficient if the variable had already been initialized to zero or null. That would mean it was initialized twice.
执行速度和开销（或缺乏）是主要原因。 C 因让你走下众所周知的悬崖而臭名昭著，因为它总是假设用户比它更了解。
请注意，如果您将变量声明为
static，它实际上保证被初始化为0。Execution speed and overhead (or lack thereof) are the main reasons why. C is notorious for letting you walk off the proverbial cliff because it always assumes that the user knows better than it does.
Note that if you declared the variable as
staticit actually is guaranteed to be initialized to 0.变量以随机值开始，因为您只是获得了一块内存并被告知要自己处理它。它具有该内存块之前具有的任何值。当您稍后可能要自己设置该值时，为什么程序要浪费时间将值设置为任意默认值？
Variables start out with a random value because you are just handed a block of memory and told to deal with it yourself. It has whatever value that block of memory had before hand. Why should the program waste time setting the value to some arbitrary default when you are likely going to set it yourself later?
设计选择是性能，这也是 C 不是大多数项目的首选语言的众多原因之一。
The design choice is performance, and it is one of the many reasons why C isn't the preferred language for most projects.
这与“如果今天设计 C”或一次初始化的效率无关。相反，想像
任何强制对您进行无用初始化的语言对于可以使用稀疏数组的算法来说都注定会慢得要命，而您不关心大多数值，并且有一种简单的方法可以知道哪些值您关心的价值观。
如果您不喜欢我的示例，在堆栈上有这么大的对象，请替换为
malloc。它在初始化方面具有相同的语义。无论哪种情况，如果您想要零初始化，可以使用
{0}或calloc来获得。This has nothing to do with "if C were being designed today" or with efficiency of one initialization. Instead think of something like
Any language that forces useless initialization on you is doomed to be slow as hell for algorithms that can make use of sparse arrays where you don't care about the majority of the values, and have an easy way of knowing which values you care about.
If you don't like my example with such a large object on the stack, substitute
mallocinstead. It has the same semantics with regard to initialization.In either case, if you want zero-initialization, you can get it with
{0}orcalloc.这是很多年前就做出的设计选择，可能是出于效率原因。
如果没有显式初始化，静态分配的变量（全局变量和静态变量）将初始化为 0 - 即使考虑到效率，这也是合理的，因为它只发生一次。我猜想，对于每次进入作用域时分配的自动变量（局部变量），隐式初始化被认为可能成本过高，因此应该由程序员负责。
如果今天设计 C，如果设计决策发生变化，我不会感到惊讶 - 特别是因为今天的编译器足够智能，能够优化在任何其他使用（或潜在使用）之前被覆盖的初始化。
然而，有很多 C 编译器工具链遵循不自动初始化的规范，因此编译器对“有用”值（如 0 或 NULL）执行隐式初始化是愚蠢的。这只会鼓励针对该工具链的人们编写在其他工具链上无法正常工作的代码。
然而，编译器可以初始化局部变量，而且它们经常这样做。只是它们将局部变量初始化为通常没有用的值（特别是，它没有设置指向空指针的指针）。这种初始化对于编写编程逻辑没有用处，而且它也不是为此目的而设计的。它的目的是导致确定性和可重现的错误，这样如果您错误地使用了隐式初始化设置的值，您将能够在测试/调试中轻松找到它。
通常，此编译器行为仅在调试版本中启用；我可以看到在发布版本中打开它的争论 - 特别是当编译器可以证明从未使用隐式初始化值时发布版本仍然可以优化它。
It was a design choice made many ears ago, probably for efficiency reasons.
Statically allocated variables (globals and statics) are initialized to 0 if there's no explicit initialization - this could be justified even taking efficiency into account becuase it only occurs once. I'd guess the thinking was that for automatic variables (locals) that are allocated each time a scope is entered, implicit initialization was considered something that might cost too much and therefore should be left to the programmer's responsibility.
If C were being designed today, I wouldn't be surprised if that design decision were changed - especially since compilers are intelligent enough today to be able to optimize away an initialization that gets overwritten before any other use (or potential use).
However, there are so many C compiler toolchains that follow the spec of not initializing automatically, it would be foolish for a compiler to perform implicit initialization to a 'useful' value (like 0 or NULL). That would just encourage people targeting that tool chain to write code that didn't work correctly on other tool chains.
However, compilers can initialize local variables, and they often do. It's just that they initialize the locals to a values that's not generally useful (especially, that doesn't set a pointer to the null pointer). That kind of initialization isn't useful in writing your programming logic against, and it's not intended for that. It's intended to cause deterministic and reproducible errors so that if you erroneously use values that have been set by implicit initialization, you'll be able to find it easily in test/debug.
Usually this compiler behavior is turned on only for debug builds; I could see an argument being made for turning it on in release builds as well - particular if the release build can still optimize it away when the compiler can prove that the implicit initialized value is never used.