[Rcpp-devel] Creating an R interface to non-copyable C++ class
Dirk Eddelbuettel
edd at debian.org
Thu Apr 12 03:14:15 CEST 2018
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
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
More information about the Rcpp-devel
mailing list