This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 29.5.2 [rand.synopsis], 99 [tr.rand.synopsis] Status: NAD Submitter: Walter Brown Opened: 2005-07-03 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [rand.synopsis].
View all issues with NAD status.
Discussion:
To accompany the concept of a pseudo-random number engine as defined in Table 17, we propose and recommend an adjunct template, engine_traits, to be declared in [tr.rand.synopsis] as:
template< class PSRE > class engine_traits;
This template's primary purpose would be as an aid to generic programming involving pseudo-random number engines. Given only the facilities described in tr1, it would be very difficult to produce any algorithms involving the notion of a generic engine. The intent of this proposal is to provide, via engine_traits<>, sufficient descriptive information to allow an algorithm to employ a pseudo-random number engine without regard to its exact type, i.e., as a template parameter.
For example, today it is not possible to write an efficient generic function that requires any specific number of random bits. More specifically, consider a cryptographic application that internally needs 256 bits of randomness per call:
template< class Eng, class InIter, class OutIter > void crypto( Eng& e, InIter in, OutIter out );
Without knowning the number of bits of randomness produced per call to a provided engine, the algorithm has no means of determining how many times to call the engine.
In a new section [tr.rand.eng.traits], we proposed to define the engine_traits template as:
template< class PSRE >
class engine_traits
{
static std::size_t bits_of_randomness = 0u;
static std::string name() { return "unknown_engine"; }
// TODO: other traits here
};
Further, each engine described in [tr.rand.engine] would be accompanied by a complete specialization of this new engine_traits template.
Proposed resolution:
[ Berlin: Walter: While useful for implementation per TR1, N1932 has no need for this feature. Recommend close as NAD. ]
Rationale: