我知道未初始化的局部变量是未定义的行为(UB),而且值可能有陷阱表示,这可能会影响进一步的操作,但有时我想使用随机数仅为视觉表示,而不会在程序的其他部分进一步使用它们,例如,在视觉效果中设置随机颜色的东西,例如:

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);
    }
}

比那么快吗

void updateEffect(){
    for(int i=0;i<1000;i++){
        star[i].setColor(rand()%255,rand()%255,rand()%255);
        star[i].setVisible(rand()%2==0?true:false);
    }
}

也比其他随机数生成器快吗?


当前回答

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

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

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

其他回答

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

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

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

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

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

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

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

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

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

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

未定义的行为意味着编译器的作者可以自由地忽略这个问题,因为无论发生什么,程序员都没有权利抱怨。

理论上,当进入UB域时,任何事情都可能发生(包括守护进程从你鼻子上飞出去),通常意味着编译器作者不会关心,对于局部变量,其值将是当时堆栈内存中的任何值。

这也意味着内容通常是“奇怪的”,但是是固定的,或者是稍微随机的,或者是可变的,但是有一个清晰的模式(例如,在每次迭代中增加值)。

当然,你不能指望它是一个不错的随机生成器。

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

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

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