This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Editorial status.
Section: 28.5.3 [rand.req], 99 [tr.rand.req] Status: NAD Editorial Submitter: Walter Brown Opened: 2005-07-03 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [rand.req].
View all issues with NAD Editorial status.
In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type, g is an ... object returning values of unsigned integral type ..."
In 5.1.1 [tr.rand.req], Paragraph 2 replace
... s is a value of integral type, g is an lvalue of a type other than X that defines a zero-argument function object returning values of
unsigned integraltype , ...
In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
creates an engine with the initial internal state determined by s
[ Mont Tremblant: Both s and g should be unsigned long. This should refer to the constructor signatures. Jens provided wording post Mont Tremblant. ]
[ Berlin: N1932 adopts the proposed resolution: see 22.214.171.124/1e and Table 3 row 2. Moved to Ready. ]
Jens: Just requiring X(unsigned long) still makes it possible for an evil library writer to also supply a X(int) that does something unexpected. The wording above requires that X(s) always performs as if X(unsigned long) would have been called. I believe that is sufficient and implements our intentions from Mont Tremblant. I see no additional use in actually requiring a X(unsigned long) signature. u.seed(s) is covered by its reference to X(s), same arguments.
[ Portland: Subsumed by N2111. ]