boost::mt19937 is sometimes used in header files as member. How do we migrate to std::mt19937 there? A typedef doesn't work, because e.g. boost::variate_generator doesn't exists in final C++11 spec (was only in tr1).
So there are two options:
According to my current understanding, when transitioning from Boost to standard library classes we should generally follow these rules:
Where | What to do
------ | --------
only in implementation | swap
private member | swap
protected member | maybe swap
public or API | introduce typedef
Speaking about random generators in particular, I found occurrences (in headers) in the following modules:
private and public;private :heavy_check_mark: private, in some places protectedprotected membersprivate :heavy_check_mark: Comments:
1] Arguably it's public in NormalGenerator by mistake, so we should actually make it private.
3] Swap. Outofcore is not a very popular module anyway, extremely unlikely that someone is maintaining his own deriving classes on top of it.
4] Random number generation is encapsulated in rnd() method, deriving classes very unlikely to deal with the generator/engine objects directly. In such a rare case users may add #if branches.
In summary, I think it's safe to swap all occasions of Boost random generators to std.
Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.
Most helpful comment
According to my current understanding, when transitioning from Boost to standard library classes we should generally follow these rules:
Where | What to do
------ | --------
only in implementation | swap
privatemember | swapprotectedmember | maybe swappublicor API | introducetypedefSpeaking about random generators in particular, I found occurrences (in headers) in the following modules:
privateandpublic;private:heavy_check_mark:private, in some placesprotectedprotectedmembersprivate:heavy_check_mark:Comments:
1] Arguably it's public in
NormalGeneratorby mistake, so we should actually make it private.3] Swap. Outofcore is not a very popular module anyway, extremely unlikely that someone is maintaining his own deriving classes on top of it.
4] Random number generation is encapsulated in
rnd()method, deriving classes very unlikely to deal with the generator/engine objects directly. In such a rare case users may add#ifbranches.In summary, I think it's safe to swap all occasions of Boost random generators to
std.