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

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

还有一种可能性需要考虑。

现代编译器(嗯，g++)非常聪明，它们会检查你的代码，看看哪些指令影响状态，哪些不影响状态，如果一条指令被保证不影响状态，g++会简单地删除那条指令。

接下来会发生什么。g++肯定会看到你正在读取，执行算术运算，保存，本质上是一个垃圾值，这会产生更多的垃圾。因为不能保证新的垃圾会比旧的垃圾更有用，所以它只会让你的循环消失。杂音!

这个方法很有用，但下面是我要做的。结合UB(未定义行为)与rand()速度。

当然，reduce rand()被执行了，但是把它们混合在一起，这样编译器就不会做任何你不希望它做的事情。

我也不会解雇你。

正如其他人所说，这将是快速的，但不是随机的。

大多数编译器对局部变量所做的是在堆栈上为它们抓取一些空间，而不是费心将其设置为任何东西(标准说它们不需要这样做，所以为什么要减慢生成的代码呢?)

在这种情况下，你将得到的值将取决于之前在堆栈上的内容——如果你在这个函数之前调用一个有100个局部char变量设置为'Q'的函数，然后在该函数返回后调用你的函数，那么你可能会发现你的“随机”值表现得就像你已经将memset()它们全部设置为'Q'。

重要的是，你的例子函数尝试使用这个，这些值不会改变每次你读取他们，他们将是相同的每一次。所以你会得到100颗星星都设置成相同的颜色和能见度。

而且，没有什么说编译器不应该初始化这些值——所以将来的编译器可能会这样做。

总的来说:坏主意，不要做。 (就像很多“聪明的”代码级优化一样……)

我喜欢你的思维方式。真的是跳出了框框。然而，这种权衡真的不值得。内存和运行时的权衡是一个问题，但运行时的未定义行为却不是。

知道自己使用如此“随机”的业务逻辑，一定会让您感到非常不安。我不会那么做的。

由于安全原因，必须清理分配给程序的新内存，否则信息可能会被使用，密码可能会从一个应用程序泄漏到另一个应用程序。只有在重用内存时，才会得到不同于0的值。很有可能，在堆栈上，前一个值是固定的，因为前一个内存的使用是固定的。

有很多很好的答案，但请允许我补充另一个并强调一点，在确定性计算机中，没有什么是随机的。对于伪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”的人。