我做了一个非常简单的测试，它根本不是随机的。

#include <stdio.h>

int main() {

    int a;
    printf("%d\n", a);
    return 0;
}

每次我运行程序，它都输出相同的数字(在我的例子中是32767)——没有比这更随机的了。这大概是运行时库中留在堆栈上的启动代码。由于每次程序运行时都使用相同的启动代码，并且在两次运行之间程序中没有其他变化，因此结果是完全一致的。

您的特定代码示例可能无法实现您所期望的功能。虽然从技术上讲，循环的每次迭代都为r、g和b值重新创建局部变量，但实际上它们在堆栈上是完全相同的内存空间。因此，它不会在每次迭代中重新随机化，你最终将为1000种颜色中的每一种分配相同的3个值，而不管r、g和b最初是多么随机。

事实上，如果它确实有效，我会非常好奇是什么让它重新随机化。我唯一能想到的就是在这个堆栈上有一个交错的中断，这是不太可能的。也许内部优化将它们作为寄存器变量，而不是真正的内存位置，在循环中寄存器被重用，这也会奏效，特别是如果设置可见性函数特别需要寄存器的话。不过，这远不是随机的。

有很多很好的答案，但请允许我补充另一个并强调一点，在确定性计算机中，没有什么是随机的。对于伪rng生成的数字和堆栈上为C/ c++局部变量保留的内存区域中发现的看似“随机”的数字都是如此。

但是…这里有一个关键的区别。

由优秀的伪随机生成器生成的数字具有统计上与真正的随机抽取相似的属性。例如，分布是均匀的。循环长度很长:在循环重复之前，你可以得到数百万个随机数。序列不是自相关的:例如，如果你取第2个、第3个或第27个数字，或者查看生成的数字中的特定数字，你不会开始看到奇怪的模式出现。

相比之下，留在堆栈上的“随机”数字没有任何这些属性。它们的值和明显的随机性完全取决于程序的构造方式、编译方式以及编译器对程序的优化方式。举例来说，这是你的想法的一个变体，作为一个自包含的程序:

#include <stdio.h>

notrandom()
{
        int r, g, b;

        printf("R=%d, G=%d, B=%d", r&255, g&255, b&255);
}

int main(int argc, char *argv[])
{
        int i;
        for (i = 0; i < 10; i++)
        {
                notrandom();
                printf("\n");
        }

        return 0;
}

当我在Linux机器上用GCC编译这段代码并运行它时，结果是相当不愉快的确定性:

R=0, G=19, B=0
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255

If you looked at the compiled code with a disassembler, you could reconstruct what was going on, in detail. The first call to notrandom() used an area of the stack that was not used by this program previously; who knows what was in there. But after that call to notrandom(), there is a call to printf() (which the GCC compiler actually optimizes to a call to putchar(), but never mind) and that overwrites the stack. So the next and subsequent times, when notrandom() is called, the stack will contain stale data from the execution of putchar(), and since putchar() is always called with the same arguments, this stale data will always be the same, too.

因此，这种行为绝对不是随机的，通过这种方式获得的数字也不具有编写良好的伪随机数生成器的任何理想属性。事实上，在大多数现实场景中，它们的值是重复的并且高度相关的。

事实上，和其他人一样，我也会认真考虑解雇那些试图把这个想法当作“高性能RNG”的人。

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

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

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

还没有提到，但是调用未定义行为的代码路径可以做编译器想做的任何事情，例如:

void updateEffect(){}

这肯定比你正确的循环快，因为有UB，是完全符合的。

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.