[PATCH] D41316: [libcxx] Allow random_device to be built optionally
Zhao, Weiming via cfe-commits
cfe-commits at lists.llvm.org
Fri Jan 5 14:37:31 PST 2018
We can wrap the random_device as a minstd_rand, a linear congruential
enginer that a lot of C lib uses for rand().
However based on documentation, we should just provides dummy
implementation which throws an exception in the constructor of
But again, compared with run-time exception, a link time error is better
if we simply skip the implementation.
"explicit random_device(const string& token = implementation-defined );
Throws: A value of an implementation-defined type derived from exception
if the random_device could not be initialized."
section 29.6.6 Class random_device (page 1082)
 "Notice that random devices may not always be available to produce
random numbers (and in some systems, they may even never be available).
This is signaled by throwing an exception derived from the standard
exception <http://www.cplusplus.com/exception> on construction
<http://www.cplusplus.com/random_device::random_device> or when a number
is requested with operator()
On 1/2/2018 11:12 AM, Arthur O'Dwyer via Phabricator wrote:
> Quuxplusone added a comment.
> @weimingz: Since your platform supports `srand(0)`, is it possible to look at how your platform implements `srand(0)` and "inline" that implementation into `random_device`? That seems like it would be more in keeping with the other ifdefs in this file.
> I'm confident that constructing an instance of `random_device` MUST NOT actually call `srand`. (I'd like to say that it shouldn't even call `rand`.) Either of those calls would be observable by the programmer. But there is a precedent for e.g. `random_shuffle` making calls to `rand`.
> rCXX libc++
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux FoundationWe
More information about the cfe-commits