[Rcpp-devel] Creating an R interface to non-copyable C++ class

JJ Allaire jj.allaire at gmail.com
Fri Apr 13 14:42:42 CEST 2018

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

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.luengo at gmail.com>

> 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 <edd at 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 | edd at debian.org
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20180413/5ebbf32e/attachment.html>

More information about the Rcpp-devel mailing list