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

[Cris Luengo]

I have some functionality in C++ that I need to access from R. My
impression was that Rcpp was the simplest way to accomplish this, but I
haven't been able to make it work yet.

The core problem, I think, is that data created is not copyable. One of
these functions returns a `std::unique_ptr` owning the pointer to the
object. Other functions take a reference to the object and modify it or
query it.

Here is what I've tried so far: https://stackoverflow.com/q/49785379/7328782

Ideally, an R variable would hold on to this pointer (with or without the
`std::unique_ptr` around it), and delete the object when it is cleared (or
garbage collected, or whatever R uses). Is this possible?

The Rcpp-extending vignette says "The macro RCPP_EXPORT_WRAP provides an
easy way to expose a C++ class to R as an external pointer", but looking at
the code it seems to allocate a new object, using `new` and the copy
constructor, and wrap that. Would it be possible to modify the code
generated by this macro to not `new`, but directly use a given pointer?
Would that still allow for lifetime management?

Many thanks for your advice!
Cris.

[Dirk Eddelbuettel]

Hi Chris,

Thanks for bringing this over here from StackOverflow.

On 11 April 2018 at 17:19, Cris Luengo wrote:
| I have some functionality in C++ that I need to access from R. My
| impression was that Rcpp was the simplest way to accomplish this, but I
| haven't been able to make it work yet.
|
| The core problem, I think, is that data created is not copyable. One of
| these functions returns a `std::unique_ptr` owning the pointer to the
| object. Other functions take a reference to the object and modify it or
| query it.
|
| Here is what I've tried so far: https://stackoverflow.com/q/49785379/7328782
|
| Ideally, an R variable would hold on to this pointer (with or without the
| `std::unique_ptr` around it), and delete the object when it is cleared (or
| garbage collected, or whatever R uses). Is this possible?

Yes. I have done things like that with eg interfaces to DB engines and alike.

One approach is to create a singleton class, and have it shield the
std::<unique_ptr>. You can add an init() function that sets things up,
possibly with arguments from R (standard string, int, ... whatever is
needed). And then add worker functions to set, get, change, ... whatever
you need give the pointer. You can add an explicit wind-down too to log,
lock, close, ... whatever you have to do with the resource.

| The Rcpp-extending vignette says "The macro RCPP_EXPORT_WRAP provides an
| easy way to expose a C++ class to R as an external pointer", but looking at
| the code it seems to allocate a new object, using `new` and the copy
| constructor, and wrap that. Would it be possible to modify the code
| generated by this macro to not `new`, but directly use a given pointer?
| Would that still allow for lifetime management?

Could it be that we are looking at lifetime from opposite sides?

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. It looks like you want to create
something that last longer than a single call from R -- and you can, and one
way is to provide something outside of R to manage it.

Does that make sense?

Dirk

[Cris Luengo]

Post by Dirk Eddelbuettel
| Ideally, an R variable would hold on to this pointer (with or without the
| `std::unique_ptr` around it), and delete the object when it is cleared (or
| garbage collected, or whatever R uses). Is this possible?
Yes. I have done things like that with eg interfaces to DB engines and alike.
One approach is to create a singleton class, and have it shield the
std::<unique_ptr>. You can add an init() function that sets things up,
possibly with arguments from R (standard string, int, ... whatever is
needed). And then add worker functions to set, get, change, ... whatever
you need give the pointer. You can add an explicit wind-down too to log,
lock, close, ... whatever you have to do with the resource.

A singleton class is equivalent to a static instance. Basically you're
suggesting a static `std::unique_ptr` that will own the object when created.
The R interface then has functions that create, modify, query and destroy
the object pointed to by the static pointer.

That could absolutely work in this case, I don't need there to be more than
one object of this class at the time. And it seems a simple approach. I will
give this a try in the morning.

Post by Dirk Eddelbuettel
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?

Many thanks!
Cris.

[Dirk Eddelbuettel]

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

[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.

Post by Dirk Eddelbuettel
| > 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
--

[JJ Allaire]

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).

Post by 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.

Post by Dirk Eddelbuettel
| > 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
--

_______________________________________________
Rcpp-devel mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel