[Rcpp-devel] returning array from C

[Steve Jaffe]

> On 11 June 2013, Dirk Eddelbuettel wrote:
> | On 11 June 2013, Steve Jaffe wrote:
> | Is there a way to 'wrap', say, an array of double allocated on the heap in C/C++ and return it to R without copying, ie as the data inside a REALSXP?
> | 
> | (Let's say for example that this array allocation is in a 3rd-party library which can't be modified)
> 
> It sounds like you may want Rcpp::XPtr -- our wrapper class around R's
> external pointers.
> ...
> | Clearly the memory ownership issue is one that would need to be handled. Handing over ownership to R would seem the simplest approach. But it would be more interesting to be able to integrate with something like boost::shared_array so that the lifetime would be correctly managed across both the C and R environments.
> 
> It is tricky.  
> 
> R really wants to control its memory, and you're either "with it" or not.
> 
> I also have some projects with oodles of boost::shared_ptr data and am not
> yet sure how best to do this.  The safest yet most expensive way is probably
> to copy it.  Or to go via XPtr.
>  
> | I've read through Rcpp documentation and "Writing R Extensions" without coming up with a good answer, but I'm new to this and I suspect someone familiar with R internals (unlike me) would immediately see what was involved.
> 
> There may not be a better answers.
> 
> As you know, R really is an interpreted system with an API for extensions.
> We are using the latter.  But R always assumes it has all the memory and can
> (and should) do the management -- hence the recommendation in "Writing R
> Extension" to not mix its allocator with external allocators.
> 
> That recommendation has worked well for us with Rcpp.  There are other use
> cases, and it is not yet clear how to integrate them.
> 
> Dirk

Thanks very much, I appreciate the advice coming from someone with your level of experience. 

I can see that mucking about with R's memory management could be dangerous and clearly copying would be the safest (and maybe only) approach. 

The problem with External Pointer is that R will not be able to use it as a numeric vector (sfaik). 

What I'm looking for -- and perhaps it is impossible -- would be a way to combine the memory semantics of External Pointer with the value semantics of Numeric Vector. Or something along those lines. 

It looks like I'd have to delve into the R source to better understand how GC is done and clearly that would be risky in that any assumptions made about the implementation that aren't exposed by the API could be broken in the future with possibly disastrous consequences. 

Steve