在任何想要使用未初始化变量的地方使用7757。我从质数列表中随机选择了它:

这是被定义的行为 它保证不总是0 它是质数 它很可能在统计上是随机的，就像未初始化一样 变量 它可能比未初始化的变量快，因为它的 值在编译时已知

如果操作得当，使用未初始化的数据来获得随机性并不一定是件坏事。事实上，OpenSSL正是这样做的，以播种它的PRNG。

显然，这种用法并没有很好地记录下来，因为有人注意到Valgrind抱怨使用未初始化的数据，并“修复”了它，导致了PRNG中的一个错误。

所以你可以这样做，但你需要知道你在做什么，并确保任何阅读你的代码的人都理解这一点。

未定义的行为是未定义的。这并不意味着你得到了一个未定义的值，这意味着程序可以做任何事情，并且仍然满足语言规范。

一个好的优化编译器应该

void updateEffect(){
    for(int i=0;i<1000;i++){
        int r;
        int g;
        int b;
        star[i].setColor(r%255,g%255,b%255);
        bool isVisible;
        star[i].setVisible(isVisible);
    }
}

并编译成noop。这当然比任何其他选择都要快。它的缺点是什么都做不了，但这就是未定义行为的缺点。

There are certain situations in which uninitialized memory may be safely read using type "unsigned char*" [e.g. a buffer returned from malloc]. Code may read such memory without having to worry about the compiler throwing causality out the window, and there are times when it may be more efficient to have code be prepared for anything memory might contain than to ensure that uninitialized data won't be read (a commonplace example of this would be using memcpy on partially-initialized buffer rather than discretely copying all of the elements that contain meaningful data).

然而，即使在这种情况下，人们也应该始终假设，如果字节的任何组合特别烦人，那么读取它总是会产生字节的模式(如果某个模式在生产中是烦人的，但在开发中不是，那么这种模式直到代码进入生产中才会出现)。

Reading uninitialized memory might be useful as part of a random-generation strategy in an embedded system where one can be sure the memory has never been written with substantially-non-random content since the last time the system was powered on, and if the manufacturing process used for the memory causes its power-on state to vary in semi-random fashion. Code should work even if all devices always yield the same data, but in cases where e.g. a group of nodes each need to select arbitrary unique IDs as quickly as possible, having a "not very random" generator which gives half the nodes the same initial ID might be better than not having any initial source of randomness at all.

正如其他人所注意到的，这就是未定义行为(UB)。

实际上，它(可能)实际上(有点)管用。在x86[-64]架构上读取未初始化的寄存器确实会产生垃圾结果，而且可能不会做任何坏事(与例如Itanium相反，那里的寄存器可以被标记为无效，因此读取会传播NaN之类的错误)。

但这里存在两个主要问题:

It won't be particularly random. In this case, you're reading from the stack, so you'll get whatever was there previously. Which might be effectively random, completely structured, the password you entered ten minutes ago, or your grandmother's cookie recipe. It's Bad (capital 'B') practice to let things like this creep into your code. Technically, the compiler could insert reformat_hdd(); every time you read an undefined variable. It won't, but you shouldn't do it anyway. Don't do unsafe things. The fewer exceptions you make, the safer you are from accidental mistakes all the time.

UB更紧迫的问题是它使整个程序的行为没有定义。现代编译器可以使用它来省略大量的代码，甚至可以回溯到过去。玩UB就像维多利亚时代的工程师拆除一个活跃的核反应堆。有无数的事情会出错，而且您可能连一半的基本原则或实现的技术都不知道。这可能没什么，但你仍然不应该让它发生。看看其他漂亮的答案来了解细节。

还有，我会炒了你。

正如其他人已经提到的，这是未定义的行为(UB)，但它可能“有效”。

除了其他人已经提到的问题之外，我还看到了另一个问题(缺点)——它不能在C和c++以外的任何语言中工作。我知道这个问题是关于c++的，但是如果你能写出好的c++代码和Java代码，这不是问题，那为什么不呢?也许有一天有人将不得不将其移植到其他语言，并且搜索像这样的“魔术”UB所导致的错误绝对是一场噩梦(特别是对于没有经验的C/ c++开发人员)。

这里有一个关于另一个类似UB的问题。想象一下，你试图在不知道这个UB的情况下找到这样的bug。如果你想阅读更多关于C/ c++中这些奇怪的东西，请阅读链接中的问题答案，并查看这个很棒的幻灯片。它将帮助你理解引擎盖下面是什么以及它是如何工作的;这不仅仅是另一个充满“魔力”的幻灯片。我确信即使是大多数有经验的C/c++程序员也能从中学到很多东西。