On Tue, Aug 28, 2012 at 4:44 AM, Paolo Carlini <paolo.carl...@oracle.com> wrote: > Again, without context, I think this is not the point: random_device is meant > to be just a simple high level wrapper > around things like dev/random, inspired by facilities like dev/random on > unix-like OSes. The brutal "fall back" we have > now in place wouldn't be useful anyway for the uses Marc is talking about, > because there is no way to provide a seed. > That said, I can't check right now C++11 about random_device, I suppose Uli > has already ;)
I did read it. random_device is all about non-determinism. Of course I know that RNGs in some situations have to be repeatable. That's what all the engines are about. random_device isn't. You use random_device to seed an engine etc. The spec says that if there is no way to create non-deterministic data the implementation may use a random number engine. "may" being to key. I perhaps didn't make myself clear as to what the big problem is. Depending on whether or not you define _GLIBCXX_USE_RANDOM_TR1 you get an object definition for 'random"device" which has the same name and mangling but has a different size. This means binary incompatibilities. Memory corruptions. Combine that problem with the fact that there is no need to fall back to pRNGs (and I'd argue it's really a bad idea because people expect real entropy and won't get any with pRNGs) and I think that just removing the pre-TR1 support will solve the issue nicely.
