Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
404 views
in Technique[技术] by (71.8m points)

c++ - Why Aren't `std::uniform_int_distribution<uint8_t>` and `std::uniform_int_distribution<int8_t>` Allowed?

As the documentation says:

The effect is undefined if this is not one of short, int, long, long long, unsigned short, unsigned int, unsigned long, or unsigned long long.

If I don't care about the range, I can just mask off the bits of a larger type to generate random numbers. If not, it's more complex. Why aren't the byte types provided just by default?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

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 that IntType and UIntType 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.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...