The XPtr is effectively a shared_ptr with special R friendly behavior. Using XPtr is as simple as just passing a pointer to your dynamically allocated C++ object to the XPtr constructor, see https://stackoverflow.com/questions/45947880/pass-a-c-object-as-a-pointer-an-reuse-in-another-function-in-rcpp
One huge benefit of using XPtr is that it has built in protection against NULL references (as any time your object is serialized/deserialized it will become invalid). It's also the case that environments like RStudio do special handling for XPtr (i.e. being sure not to suspend RStudio Server sessions that have a live XPtr). On Thu, Apr 12, 2018 at 2:15 PM, Cris Luengo <cris.l.lue...@gmail.com> wrote: > Hi Dirk, > > I found a more generic solution than a singleton class. I'm extracting > the pointer out of the `std::unique_ptr` using `release`, and putting it > into a `std::shared_ptr`. This one can easily be wrapped using the > standard Rcpp mechanisms. > > This is maybe not the best way to do it, I also followed your > recommendation to look into `Rcpp::XPtr`, and it seems that it > should be possible to pass it a raw pointer and construct a > SEXP around it. But that's more code to write, I like the simple > solutions... > > Many thanks for your help! > Cris. > > > > > On 12 April 2018 at 05:42, Dirk Eddelbuettel <e...@debian.org> wrote: > >> >> On 11 April 2018 at 23:54, Cris Luengo wrote: >> | > The way R thinks about this is that _it_ owns everything, and Rcpp >> makes >> | > getting things back and forth _using the R memory system and its >> lifetime / >> | > reference count control_ fairly easy. >> | >> | Yes, that makes sense. But somehow it is not easy to transfer ownership >> | of an object to R. There needs to be a new object created that it can >> own? >> >> Yes, in general that works just fine. Ie when we do >> >> Rcpp::NumericVector x(10); >> >> we use the R malloc functions, and to R this _is_ the same as a REAL with >> 10 >> elements. Because everything has to be a SEXP, our C++ objects are really >> proxies to underlying SEXPs. And R is happy. And controls everything and >> it >> all works as if you used the C API of R. Which we extend (by a lot, you >> could say) to make things easier. >> >> A unique_ptr with _control on the C++ side_ does not fit that mold at all >> so >> we have to do something different here. The singleton / static instance >> is >> one approach _so that it survives across multiple (different) calls_ from >> R. >> >> I am sure there are other approaches, but they still have to match the >> basic >> constraint of 'SEXP in, SEXP out'. >> >> Hth, Dirk >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> > > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel@lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
