[Rcpp-devel] Idiom for preserving an Rcpp object while passing back an external pointer?

[Dirk Eddelbuettel]

On 5 February 2011 at 08:52, Douglas Bates wrote:
| As Dirk and Romain know I have been struggling to debug a memory
| protection problem that I encounter in code based on Rcpp Modules.  As
| with all memory protection problems, it is very difficult to track
| down and I have kind-of run out of options right now.

Yes, sorry, I wish your code wouldn't run into this. My much lighter use of
Modules has help up so far.  
 
| I plan, for the time being, to use code that acts like the
| module-based code without going through the modules.  I plan to create
| the object in C++ and pass back an external pointer that will be used
| to locate the object for later method calls.  Perhaps it is lack of
| imagination but I haven't thought of a way to construct an object and
| make it persistent until I decide to release the pointer.  The best
| way I have been able to derive is to put the C++ object on a global
| stack but that approach screams "error-prone".
| 
| My question may be somewhat vaguely stated.  What I am trying to avoid
| is creating an object in C++ and returning an Rcpp::XPtr then, on
| return to R, having the C++ object go out of scope so the external
| pointer's target is gone.  Somehow I need to hold on to the C++ object
| until the XPtr object is garbage collected.
| 
| Suggestions welcome.

One heavy-handed approach would be old-school stack based, ie either a global
array or a static one as in

      static myClass pool[ N ];

and you then hand out elements of this array.  That avoids garbage collection
alltogether.  There are loads of C++ implementations of memory pools out there as there are
performance sensitive applications that want to avoid allocation, garbage
collection, ... at the C++ layer too.  Google finds lots of pahes for 'C++
memory pool' and e.g. the good folks at Boost have something too 

    http://www.boost.org/doc/libs/1_45_0/libs/pool/doc/index.html

but I should add that never used this Boost library.

A somewhat lighter approach could still work with XPtr. When I used objects
via external pointers them, I think I just bound allocation to their ctor and
dtor. Should that not be enough to protect the object from R's garbage
collection?  Mind you, I generally created few and large objects which
persisted (eg using bigmemory); what you do probably involves orders of
magnitude more objects which is probably why the bug rears its ugly head.

Dirk

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com