Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.

782. Extendedseed_seq constructor is useless

Section: 29.5.8.1[rand.util.seedseq]Status:CD1Submitter: Daniel KrüglerOpened: 2008-01-27Last modified: 2015-10-20

Priority:Not Prioritized

View all otherissues in [rand.util.seedseq].

View all issues withCD1 status.

Discussion:

Part of the resolution of n2423, issue 8 was the proposal toextend theseed_seq constructor accepting an input rangeas follows (which is now part of N2461):

template<class InputIterator,size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>seed_seq(InputIterator begin, InputIterator end);

First, the expressioniterator_traits<InputIterator>::value_typeis invalid due to missingtypename keyword, which is easy tofix.

Second (and worse), while the language now supports defaulttemplate arguments of function templates, this customizationpoint via the secondsize_t template parameter is of no advantage,becauseu can never be deduced, and worse - because it is aconstructor function template - it can also never be explicitlyprovided (13.10.2[temp.arg.explicit]/7).

The question arises, which advantages result from a compile-timeknowledge ofu versus a run time knowledge? If run time knowledgesuffices, this parameter should be provided as normal functiondefault argument [Resolution marked (A)], if compile-time knowledgeis important, this could be done via a tagging template or moreuser-friendly via a standardized helper generator function(make_seed_seq), which allows this [Resolution marked (B)].

[Bellevue:]

Fermilab does not have a strong opinion. Would prefer to go withsolution A. Bill agrees that solution A is a lot simpler and does thejob.

Proposed Resolution: Accept Solution A.

Issue803⁽ⁱ⁾ claims to make this issue moot.

Proposed resolution:

1. In 29.5.8.1[rand.util.seedseq]/2, classseed_seq synopsis replace:

   class seed_seq { public:   ...   template<class InputIterator,      size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>          seed_seq(InputIterator begin, InputIterator end,          size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits);   ...};

   and do a similar replacement in the member description betweenp.3 and p.4.

2. In 29.5.8.1[rand.util.seedseq]/2, classseed_seq synopsisand in themember description between p.3 and p.4 replace:

   template<class InputIterator,  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>      seed_seq(InputIterator begin, InputIterator end);template<class InputIterator, size_t u>seed_seq(InputIterator begin, InputIterator end,implementation-defined s);

   In 29.5.2[rand.synopsis], header<random> synopsis, immediately after theclassseed_seq declarationand in 29.5.8.1[rand.util.seedseq]/2, immediatelyafter the classseed_seq definition add:

   template<size_t u, class InputIterator>  seed_seq make_seed_seq(InputIterator begin, InputIterator end);

   In 29.5.8.1[rand.util.seedseq], just before p.5 insert two paragraphs:

   The first constructor behaves as if it would provide anintegral constant expressionu of typesize_t of valuenumeric_limits<typename iterator_traits<InputIterator>::value_type>::digits.

   The second constructor uses an implementation-defined mechanismto provide an integral constant expressionu of typesize_t andis called by the functionmake_seed_seq.

   In 29.5.8.1[rand.util.seedseq], just after the last paragraph add:

   template<size_t u, class InputIterator>   seed_seq make_seed_seq(InputIterator begin, InputIterator end);

   whereu is used to construct an objects of implementation-defined type.

   Returns:seed_seq(begin, end, s);