Title
Random number engine constructor concerns
Status
c++11
Section
[rand.eng]
Submitter
BSI

Created on 2010-08-25.00:00:00 last changed 161 months ago

Messages

Date: 2011-05-21.21:15:19

Proposed resolution:

Add the following paragraph at the end of [rand.eng]:

5 Each template specified in this section [rand.eng] requires one or more relationships, involving the value(s) of its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if any such required relationship fails to hold.

? For every random number engine and for every random number engine adaptor X defined in this sub-clause [rand.eng] and in sub-clause [rand.adapt]:

  • If the constructor
    template<class Sseq> explicit X(Sseq& q);
    

    is called with a type Sseq that does not qualify as a seed sequence, then this constructor shall not participate in overload resolution.

  • If the member function
    template<class Sseq> void seed(Sseq& q);
    

    is called with a type Sseq that does not qualify as a seed sequence, then this function shall not participate in overload resolution.

The extent to which an implementation determines that a type cannot be a seed sequence is unspecified, except that as a minimum a type shall not qualify as seed sequence, if it is implicitly convertible to X::result_type.

Date: 2010-11-24.14:01:03

[ Adopted at 2010-11 Batavia ]

Date: 2010-11-11.19:16:05

[ 2010 Batavia: There were some initial concerns regarding the portability and reproducibility of results when seeded with a negative signed value, but these concerns were allayed after discussion. Thus, after reviewing the issue, the working group concurred with the issue's Proposed Resolution. ]

Date: 2010-11-04.00:00:00

[ 2010-11-04 Howard suggests to use !is_convertible<Sseq, result_type>::value as minimum requirement instead of the originally proposed !is_scalar<Sseq>::value. This would allow for a user-defined type BigNum, that is convertible to result_type, to be used as argument for a seed instead of a seed sequence. The wording has been updated to reflect this suggestion. ]

Date: 2010-11-03.00:00:00

[ 2010-11-03 Daniel comments and provides a proposed resolution: ]

I suggest to apply a similar solution as recently suggested for 1234. It is basically a requirement for an implementation to constrain the template.

Date: 2010-10-24.03:04:13

Addresses GB-121

All the random number engine types in this clause have a constructor taking an unsigned integer type, and a constructor template for seed sequences. This means that an attempt to create a random number engine seeded by an integer literal must remember to add the appropriate unsigned suffix to the literal, as a signed integer will attempt to use the seed sequence template, yielding undefined behaviour, as per 26.5.1.1p1a. It would be helpful if at least these anticipated cases produced a defined behaviour, either an erroneous program with diagnostic, or a conversion to unsigned int forwarding to the appropriate constructor.

History
Date User Action Args
2011-08-23 20:07:26adminsetstatus: wp -> c++11
2010-11-24 14:01:03adminsetmessages: + msg5433
2010-11-14 13:10:57adminsetstatus: voting -> wp
2010-11-13 01:17:02adminsetstatus: open -> voting
2010-11-13 01:11:40adminsetstatus: immediate -> open
2010-11-11 19:16:05adminsetmessages: + msg5331
2010-11-11 19:16:05adminsetstatus: open -> immediate
2010-11-05 18:23:50adminsetmessages: + msg5294
2010-11-03 21:20:39adminsetmessages: + msg5284
2010-11-03 21:20:39adminsetmessages: + msg5283
2010-10-24 03:04:13adminsetmessages: + msg4930
2010-08-25 00:00:00admincreate