Is it OK that the string of numbers generated by std::random_device is the same every time?

I don't think it's a good idea to fix the species and produce the same string of numbers every time (=easily predictable).

It's not a desirable behavior, but I think it's barely compliant with the C++ standard.++ standard.In other words, it is within the scope of "implementation-defined" and is simply an interpretation that the quality of the implementation is significantly lower.(Whether to call it a defect or not depends on the criteria?)

On a different point of view, check if std::random_device{}.entropy()==0.0 in your environment.entropy() is designed to return zeroes when a non-deterministic random sequence cannot be returned due to processing problems.

Related C++11 Specifications 26 26.5.6 [land.device] Quoted by respondents:

1 A random_device uniform random number generator processes non-deterministic random numbers.
2 If implementation limits prevent generating non-deterministic random numbers, the implementation may deploy a random number engine.

explicit random_device(const string & token=implementation-defined);
3Effects:Constructs arandom_devicenon-deterministic uniform random number generator object.The semantics and default value of the token parameter are implementation-defined.

double entropy() const noxcept;
5Returns:If the implementation deploys a random number engine, returns 0.0.Otherwise, returns an entropy estimate for the random numbers returned by operator(), in the range min()

Note: Although it is described as "fixed species", random_device constructors are given tokens (token) to processing systems, not seeds (seed) to random number generation engines.The original intention is to "select" a random number generating engine from several choices.

This is the main entity of the std::random_device of the GCC.

• gcc/libstdc++-v3/include/bits/random.h
• gcc/libstdc++-v3/src/c++11/random.cc

It is located in .Preprocessor macros branch off at compile time.

There are two influences.Then the actual operation is

• When compiling the library, _GLIBCXX_USE_RANDOM_TR1 is defined
• When compiling an application, the std:random_device constructor argument is passed with "default"
• When compiling the library, _GLIBCXX_X86_RDRAND is defined
• Test if the CPU supports the RDRAND instruction when running the application

When all the conditions were met, the implementation used the RDRAND instruction without using /dev/urandom.

Personally, I think the priority of using RDRAND is wrong.Even if _GLIBCXX_USE_RANDOM_TR1 is forcibly defined during application compilation, the required library functions are not prepared, so even if the compilation succeeds, it will still result in a link error.

I didn't answer any questions because I was always explaining.

In MinGW version of GCC, the default constructor for std::random_device generates the same number column every time, but is this behavior compliant with the standard?

Quote bits/random.h L1568 to L1587.

#ifdef_GLIBCXX_USE_RANDOM_TR1

    explicit
    random_device(conststd::string&__token="default")
    {
      _M_init(_token);
    }

    ~random_device()
    { _M_fini();}

# else

    explicit
    random_device(const std::string&__token="mt19937")
    { _M_init_pretr1(_token);}

  public:

#endif

For GCC, the environment in which _GLIBCXX_USE_RANDOM_TR1 is defined (i.e., it has either /dev/random or /dev/urandom device files, other than MinGW) is random_device:_M_init() but not defined in the environment.