As the documentation says:
The effect is undefined if this is not one of
short
,int
,long
,long long
There is a library working group unresolved[1] issue on this uniform_int_distribution<unsigned char> should be permitted and it says, amongst other things:
I am not aware of anything in
<random>
that works with 16-bit integers but fails with 8-bit integers, so I suspect thatIntType
andUIntType
could simply be extended to permit the char family. Alternatively, this change could be limited to uniform_int_distribution alone, where it is definitely safe. A<random>
expert should decide which change is best.
The proposed resolution is to change the restriction to allow standard integer types:
that has a template type parameter named
IntType
is undefined unless the corresponding template argument is cv-unqualified and is a a standard integer type (3.9.1 [basic.fundamental]
and:
that has a template type parameter named
UIntType
is undefined unless the corresponding template argument is cv-unqualified and is a standard unsigned integer type (3.9.1 [basic.fundamental])
This gets you unsigned / signed char although not uint8_t or int8_t but they are likely equivalent. Extended integral types were exluded to simplify the wording and maximize consensus:
This also excludes extended integral types and wide char types, which seem like nice-to-haves at best. I have no objection to supporting any of those types; I just picked this to simplify the wording and hopefully maximize consensus.
Note, this excludes char
since it is implementation defined whether char
is signed or not.
Note this topic was also brought up in the std-discussion list.
Jonathan Wakely notes this proposal is controversial and commented that his notes from the last discussion include the following:
that it was very definitely intentional that single byte integers are not supported, not an accidental omission, and so we should be careful about just changing that without consulting the designers of the C++11
He suggests adding a member to random_device
to provide single bytes, which is seems like a reasonable alternative.
[1] The issue has been closed as "Not A Defect", meaning that it will not be resolved as a defect report. Instead a formal proposal for the change will be required.