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

[Cris Luengo]

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

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


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

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

[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::.  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 | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] segmentation fault when wrapping a big Eigen 2-d array

[Dirk Eddelbuettel]

On 9 April 2018 at 09:51, Jack Wasey wrote:
| I seem to tread in unusual code paths often, which is
| why I appreciate so much your guidance. I can't reproduce the error now
| I've converted from integer Eigen matrix to Rcpp::IntegerMatrix, then
| within Rcpp, Integer to Logical matrices. 

I think it is super tempting to write compact code like that.  But the
template magic is a little fragile, and nesting does not seem to help.  So I
just learned to be defensive and do it one step at time..

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[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.
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel