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-rc
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 fol
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 eas
> On Apr 11, 2018, at 19:14, Dirk Eddelbuettel wrote:
>
> On 11 April 2018 at 17:19, Cris Luengo wrote:
> | 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
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.
|
