<div dir="ltr">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 <a href="https://stackoverflow.com/questions/45947880/pass-a-c-object-as-a-pointer-an-reuse-in-another-function-in-rcpp">https://stackoverflow.com/questions/45947880/pass-a-c-object-as-a-pointer-an-reuse-in-another-function-in-rcpp</a><div><br></div><div>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).</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 12, 2018 at 2:15 PM, Cris Luengo <span dir="ltr"><<a href="mailto:cris.l.luengo@gmail.com" target="_blank">cris.l.luengo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi Dirk,<br><br></div>I found a more generic solution than a singleton class. I'm extracting<br></div>the pointer out of the `std::unique_ptr` using `release`, and putting it<br></div>into a `std::shared_ptr`. This one can easily be wrapped using the<br></div>standard Rcpp mechanisms.<br><br>This is maybe not the best way to do it, I also followed your<br>recommendation to look into `Rcpp::XPtr`, and it seems that it<br></div><div>should be possible to pass it a raw pointer and construct a<br></div><div>SEXP around it. But that's more code to write, I like the simple<br></div><div>solutions...<br><br></div><div>Many thanks for your help!<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Cris.<br><br></div><div><br><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 12 April 2018 at 05:42, Dirk Eddelbuettel <span dir="ltr"><<a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
On 11 April 2018 at 23:54, Cris Luengo wrote:<br>
| > The way R thinks about this is that _it_ owns everything, and Rcpp makes<br>
| > getting things back and forth _using the R memory system and its lifetime /<br>
| > reference count control_ fairly easy.<br>
|<br>
| Yes, that makes sense. But somehow it is not easy to transfer ownership<br>
| of an object to R. There needs to be a new object created that it can own?<br>
<br>
</span>Yes, in general that works just fine. Ie when we do<br>
<br>
   Rcpp::NumericVector x(10);<br>
<br>
we use the R malloc functions, and to R this _is_ the same as a REAL with 10<br>
elements.  Because everything has to be a SEXP, our C++ objects are really<br>
proxies to underlying SEXPs. And R is happy. And controls everything and it<br>
all works as if you used the C API of R.  Which we extend (by a lot, you<br>
could say) to make things easier.<br>
<br>
A unique_ptr with _control on the C++ side_ does not fit that mold at all so<br>
we have to do something different here.  The singleton / static instance is<br>
one approach _so that it survives across multiple (different) calls_ from R.<br>
<br>
I am sure there are other approaches, but they still have to match the basic<br>
constraint of 'SEXP in, SEXP out'.<br>
<br>
Hth, Dirk<br>
<div class="m_12997397313489606HOEnZb"><div class="m_12997397313489606h5"><br>
--<br>
<a href="http://dirk.eddelbuettel.com" rel="noreferrer" target="_blank">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Rcpp-devel mailing list<br>
<a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-<wbr>project.org</a><br>
<a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" rel="noreferrer" target="_blank">https://lists.r-forge.r-<wbr>project.org/cgi-bin/mailman/<wbr>listinfo/rcpp-devel</a><br></blockquote></div><br></div>