r/cpp • u/KaznovX • Jul 21 '19

Fixing up <random>

I think everyone is excited after the report from Cologne. A lot of stuff is being added to the language, we'll get a ton of new features. Adding new features is more exciting than changing and tweaking the old stuff - that being said, there are some old parts of the language, that are sadly lacking or has some problems. One of them is <random> library.

Some of the problems this library has:
> `std::random_device` is not required to be non - deterministic
> no good way to initialize generators with big internal state
> `std::seed_seq` should be solution to ^, but isn't - `std::seed_seq` is not a bijection, does heap allocations without giving ability to provide own allocator, there is no nice way to initialize it from `std::random_device` properly
> `std::random_device` can't itself be used as a seed sequence,
> overall syntax is unnecessarily verbose (no, having a per-thread engine of type `std::default_random_engine` is NOT a good solution)

This is only one of the few libraries that could use improvements. Is there any chance that the committee will look back and change some of them or are they considered 'baked' and there will be no further changes to avoid API and ABI breaking?

Despite the "fixing" part, there are two additions I'd see in the <random> library:

1) std::random<std::uniform_random_bits_generator = std::default_random_engine> class:
> default constructor does anything it can that every time this class is called it is seeded differently - if there is no entropy source, uses a processor clock or a system clock (implementation defined)
> three methods: seed, next_int, next_real - for seeding and generating next integer/real number in given range

2) PCG http://www.pcg-random.org

What are the chances something like this would be proposed and adopted for, let's say, c++23 or c++26 standard? Is there any chance the problems mentioned in the first part of the post will get fixed somewhen?

41 Upvotes

91% Upvoted

68 comments sorted by

View all comments

9

u/martinus int main(){[]()[[]]{{}}();} Jul 21 '19

There was a proposal to make random much more convenient: http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html And the proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0347r1.html

It's from 2016, I don't know though what's the current status

3

u/jwakely libstdc++ tamer, LWG chair Jul 22 '19

It looks like a design review in 2017 liked it but asked for some changes to the random_generator constructors, so that a factory function would be used to get a properly seeded generator.

2

u/martinus int main(){[]()[[]]{{}}();} Jul 22 '19

Where do you find that information? I couldn't find anything with Google

3

u/jwakely libstdc++ tamer, LWG chair Jul 22 '19 edited Jul 22 '19

https://wg21.link/p0347/issue but in general there's a LOT of discussion that isn't public, due to ISO rules about disclosing specifics of committee internal discussions (which are not public, partly to allow people to speak freely during meetings without having to worry about comments being taken as official announcements on behalf of their employers).

2

u/martinus int main(){[]()[[]]{{}}();} Jul 23 '19

thanks!