0

Section 29.6.1.1 of the C++11 standard restricts the UIntType argument to a <random> engine template to unsigned short and larger. Behaviour for other types - specifically unsigned char - is undefined.

While GCC (4.9.2, at least) accepts unsigned char, the VS2017 compiler errors out due to a static assert on the type.

My questions are:

  1. Why is behaviour for char types not defined by the standard?

  2. Does VS2017 prohibit this for technical reasons, or simply to prevent nonstandard usage?

Jeremy
  • 5,055
  • 1
  • 28
  • 44
  • The standard says it's not valid. You gave invalid code to compilers which sometimes gives you an error and sometimes seems to do something else. Isn't that the expected behavior? – nwp Jan 05 '18 at 09:28
  • (unless you're interested in the technical reasons why engines requires at least a short there) this question is essentially a duplicate of [What is the difference between undefined, unspecified, and implementation-defined behavior in C and C++?](https://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior) – Massimiliano Janes Jan 05 '18 at 10:24
  • 1
    Yes, "the technical reasons why engines requires at least a short there" is exactly what I'm interested in. – Jeremy Jan 05 '18 at 10:48
  • 1
    well, UIntType is the parameter name collectively chosen to represent unsigned integer parameters of facilities, including random engines; now, the only types smaller than a short are those having sizeof(T)==1, hence with limits::max == 255; so, I guess the answer to your question is that 255 is just too small for *some* engine (eg linear_congruential) to reasonably satisfy random engine semantics – Massimiliano Janes Jan 05 '18 at 11:10

1 Answers1

0

Assuming your question is about the technical reasons why <random> engines requires at least a short as their unsigned template parameters, and not about the general meaning of undefined behaviour in C++.

UIntType is the parameter name collectively chosen to represent unsigned integer parameters of <random> facilities, mainly random engines (I suppose for the sake of simplifying and uniformizing the library requirements).

Now, the only types smaller than a short are those having sizeof(T)==1, hence practically having limits<T>::max == 255; so, I guess the answer to your question is that 255 is just too small for some(all?) engines to reasonably satisfy random engine semantics under any circumstances.

For example, IIRC linear_congruential would have a maximal period of 64 and badly uneven distribution in that case; such a thing could be hardly called a pseudo random generator even for the dumbest application scenarios.

Requiring implementations to provide 'functional' unsigned char specializations would be sadistic, to say the least. Of course, being the behaviour undefined, nothing forbids an implementation to omit diagnostic in that case, or even providing such specializations for whatever reason...

Massimiliano Janes
  • 5,524
  • 1
  • 10
  • 22
  • But why apply that reasoning, which may well apply to engines, to adaptors (such as `independent_bits_engine`) and distributions (such as `uniform_int_distribution`), both of which can be used perfectly reasonably to produce 1-bit output (let alone 8-bit)? – Jeremy Jan 05 '18 at 13:27
  • @Jeremy adaptors and distributions are defined in terms of engines; so, even if it's conceptually possible to allow it, they would practically inherit the same limits (or make their implementations worthlessly more complex); moreover, this would cost defining an extra layer of requirements just for that, is it worth it ? – Massimiliano Janes Jan 05 '18 at 13:32
  • Strictly speaking, only adaptors are defined in terms of engines - and the entire point of an adaptor is to adapt an engine in some way (and note that `independent_bits_engine`'s `UIntType` is explicitly specified independently of that of the base engine.) But in any case I doubt that an extra layer of requirements would be needed - just an additional restriction on UIntType when applied to random number engines (or alternatively a slight relaxation of the restriction when applied to adaptors and distributions). – Jeremy Jan 05 '18 at 13:55
  • Which is kind of the point of my question: to what extent is excluding char types simply for convenience in the wording of the standard, and to what extent is it for an underlying technical reason? – Jeremy Jan 05 '18 at 13:57