[Rcpp-devel] rcpp_modules: Passing object pointer back to C++

[Mr.M at gmx.at]

Hello again and thanks for the many replies.

Well, Dirk,

I haven't dealt with Rcpp and S4 long enough to understand every piece of it, so I'll try to explain my thoughts with examples.

In R:
a = new (MyPackage::TestClass)

This allocates a memory area for the S4 object and the C++ object. Both are managed by R -> if the R object "a" runs out of scope, the R GC might unallocate the memory area and it might be overwritten by something else in future.

This "TestClass" -in my case- wraps a "normal" C++-class which does whatever it wants(!) -> including calling the C++ standard "new" and "delete" for allocating contained objects.
The important part is, that this "normal" C++class does not rely on the R-managed-"new" to do clean up. Instead it has a standard C++ ~destructor() which does the unallocation via the C++ "delete".
Doing unallocation properly is the responsibility of the C++ class (as it always has been). Otherwise memory leaks occur which fill up the virtual memory of the program (or R-session in this case).

---

In R:
b = new (MyPackage::TestClass)
a$doSomething(b)

The C++ function takes the object "b", gets the raw C++ pointer to its memory, and then does something with it. (As shown in my previous post; Nothing is being allocated there; also nothing gets "copied")

Option 1: "doSomething" only "reads" some primitive data from the object "b".
There should not be anything wrong with that, since the R is single threaded by default and the pointer to the object (or its content) should not change during the invocation of the function.

Option 2: "doSomething" calls a function in "b" which then calls C++ standard "new" for member variable "x" somewhere inside "b".
This should not be a problem, because the pointer to the allocated memory area of "x" is stored in "b". The destructor of "b" is responsible for unallocating "x" when "b" gets unallocated by the R GC when "b" runs out of scope in R. (phew...)

Option 3: "doSomething" stores the passed pointer to "b" in a member variable of "a".
This is somewhat of a problem, if "a" uses this member variable to object "b" in subsequent calls to "a".
BECAUSE: R might change the location of the object "b" in memory between R function calls. And "a" still has the old pointer to "b". -> Causes unpredictable behaviour or segfault.

So, the important questions (for an inexperienced Rcpp_modules user like me) are:
1) Does R call the destructor of rcpp_modules S4 C++ objects when the R GC unallocates them? (hopefully "yes")
2) Does R change the location of rcpp_modules S4 C++ objects in memory during their lifetime? (hopefully "no")


regards,
Michael M.

-------- Original-Nachricht --------
> Datum: Sun, 22 Jan 2012 18:20:17 -0600
> Von: Dirk Eddelbuettel <edd at debian.org>
> An: Mr.M at gmx.at
> CC: Jelmer Ypma <jelmerypma at gmail.com>, rcpp-devel at r-forge.wu-wien.ac.at
> Betreff: Re: [Rcpp-devel] rcpp_modules: Passing object pointer back to C++

> 
> Michael,
> 
> Can you mock up a more complete example of what you are trying to do?  
> 
> I am a little worried about the lifecycle of objects allocated that way,
> about who owns them, and what happens to the memory. From my casual look
> at
> it, Jelmer's code is pretty clever but I am not sure calling R's new() to
> allocate inside of what you consider a C++ object might be too clever by
> half
> and hurt you later.
> 
> Rcpp::XPtr() will always fit in the framework of .Call() functions
> receiving
> and returning SEXP. 
> 
> On the other hand, Rcpp modules are very useful, but also known to have
> limits as eg the lack of serialization/deserialization for load and save.
> 
> Dirk
> 
> -- 
> "Outside of a dog, a book is a man's best friend. Inside of a dog, it is
> too
> dark to read." -- Groucho Marx

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail