Code review - <random> library user-created toolkit

[E0p9LyTq]

Several month ago I had downloaded a technical paper (pdf) on random number generation in C++11 and have been digesting the contents.

The paper: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3551.pdf

One part of the paper really intrigued me, the simple toolkit. I noticed it was written as stand-alone functions. I decided to see if I could encapsulate the functionality into a class.

Long story short, it works for me. But I don't know if there are potential problems that could show up, so would like some expert advice.

class URNG
{
public:
   URNG() {}
   ~URNG() {}

public:
   std::default_random_engine& GetGenerator() { return dre; }

public:
   void randomize();

public:  // generic random number generation functions
   int pick_a_number(const int from, const int thru);
   double pick_a_number(const double from, const double upto);

private:
   std::default_random_engine dre;
};


void URNG::randomize()
{
   std::random_device rd {};
   dre.seed(rd());
}


int URNG::pick_a_number(const int from, const int thru)
{
   static std::uniform_int_distribution<> dist {};
   using parm_t = decltype(dist)::param_type;
   return dist(dre, parm_t { from, thru });
}


double URNG::pick_a_number(const double from, const double upto)
{
   static std::uniform_real_distribution<> dist {};
   using parm_t = decltype(dist)::param_type;
   return dist(dre, parm_t { from, upto });
}

I do know that using default_random_engine will not work with GCC-based compilers, it is a known bug as several people pointed out in other topics. It seems to work with VS 2015 without causing problems.

This was done as a learning experience, there is a lot of real world considerations I deliberately avoided dealing with.

Was encapsulating the stand-alone functions in a class a wrong approach? Are there hidden "undefined errors" lurking that I don't see?

[helios]

What's the point of making the distribution objects static?
What do you gain from the class over directly using the standard objects?

[E0p9LyTq]

helios wrote:

What's the point of making the distribution objects static?

That was used when it was stand-alone functions as outlined in the working paper.

I was considering removing the static usage, it is useless/overkill for the way the class is structured, but hadn't done it yet. Now I will.

helios wrote:

What do you gain from the class over directly using the standard objects?

Better encapsulation of combining functions/functionality with an object.

There is no real need to do it beyond having a user-created library header file I can "plop" into a project. Declare an object and have functions I deem useful bound to the object.

Does creating a class encapsulating standard objects create problems that are unsolvable or bloat? I can't see any, but I'm not an expert.

[helios]

I just don't really see the point. The standard classes are already a pretty good abstraction that separates the randomness source from the distribution. Merging them back together seems like a step backwards.

[E0p9LyTq]

Why climb a mountain? I did this to see if it was possible.

[helios]

Is this really comparable to climbing a mountain? I think it's closer to "I always go to the store next door by walking straight to it, but today I'm going to see if I can also do it by going around the entire block".
You've verified that, yes, indeed it is possible. Great. Is there any reason to do this this way?