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 <[email protected]> > An: [email protected] > CC: Jelmer Ypma <[email protected]>, [email protected] > 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 _______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
