You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In PR #58 it was discussed if it makes sense to change the way the RNG is stored within dqrng.
Currently the RNG is stored as dqrng::rng64_t == std::shared_pointer<dqrng::random_64bit_generator> where dqrng::random_64bit_wrapper<RNG> provides the actual storage.
Keeping with the standard C++ smart pointers std:unique_ptr might make more sense.
Switching to Rcpp::XPtr would simplify the code for sharing the RNG externally. It would make sense the assert the life cycles of XPtr objects are copy-construction on rcpp-devel, c.f. feat: global RNG access #58 (comment).
The text was updated successfully, but these errors were encountered:
According to the discussion on rcpp-devel, a Rcpp:XPtr would indeed work quite well. It behaves like a smart pointer that releases the content only when the last XPtr object gets out of scope. So this would be sort of ideal for this use case. Changing dqrng::rng64_t would be a breaking change, but we are doing this in this release anyway. And at least on CRAN I have not seen anybody actually programming against the C++ API or using the header only libraries beyond just including one of the RNGs and and maybe seeding from R.
FWIW I use Rcpp::XPtr quite a lot, for example here; which is then passed around all of my C++ functions in the same package; and even across shared library boundaries in different packages, e.g., here. Seems to work pretty well, and at 10k downloads a month, I haven't seen any catastrophic segfaults/bus errors/other weirdness... yet.
The only thing to note is that anyone saving their R session will invalidate the external pointer (obviously). It seems that invalidation yields a NULL pointer so you can check for that and re-init the pointer when necessary, e.g., here.
In PR #58 it was discussed if it makes sense to change the way the RNG is stored within dqrng.
dqrng::rng64_t == std::shared_pointer<dqrng::random_64bit_generator>
wheredqrng::random_64bit_wrapper<RNG>
provides the actual storage.std:unique_ptr
might make more sense.Rcpp::XPtr
would simplify the code for sharing the RNG externally. It would make sense the assert the life cycles ofXPtr
objects are copy-construction on rcpp-devel, c.f. feat: global RNG access #58 (comment).The text was updated successfully, but these errors were encountered: