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

[Cris Luengo]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20180412/5e0ee54c/attachment.html>