[Rcpp-devel] reference counting, garbage collection, etc ....

| Right, so looking at R_PreserveObject and R_ReleaseObject (still waiting 
| for some insight from R-devel) it seems that we can preserve and release 
| the same SEXP more than once. preserve adds the sexp to the list of 
| preserved SEXP (even if it is there already), and release release the 
| first one it finds.
| 
| This leads me to thinking that we should make the garbage collection 
| stuff automatic and hidden, i.e when setting the SEXP of an RObject, we 
| automatically preserve it, and we release it automatically when the 
| object goes out of scope.

That was always the idea with Rcpp objects.  The classes manage memory, the
user doesn't have to worry.

And the design was always like this -- release memory in the dtor.
 
| Currently we have to manage this business manually, which will leads to 
| problems.

"We" as in class implementers/authors, or "we" as users?   As authors, yes we
do have to manage this, but that is because R forces us to, no?

| So i propose that RObject::m_sexp becomes private (as opposed to 
| protected) and we had a protected setSEXP that :
| - release the current SEXP if there is one
| - preserve the new SEXP
| 
| and make preserve and release protected (maybe even private members of 
| RObject), and remove the preserved bool.

Sounds like a technically more sounds implementation, but nothing really
changes for the user, no?  Ie there never was a user-accessibly method to 
unprotect/unpreserve.

Am I missing something?   

Dirk

Three out of two people have difficulties with fractions.

On 2 January 2010 at 13:37, Romain Fran?ois wrote:
| Right, so looking at R_PreserveObject and R_ReleaseObject (still waiting
| for some insight from R-devel) it seems that we can preserve and release
| the same SEXP more than once. preserve adds the sexp to the list of
| preserved SEXP (even if it is there already), and release release the
| first one it finds.
|
| This leads me to thinking that we should make the garbage collection
| stuff automatic and hidden, i.e when setting the SEXP of an RObject, we
| automatically preserve it, and we release it automatically when the
| object goes out of scope.

That was always the idea with Rcpp objects.  The classes manage memory, the
user doesn't have to worry.

And the design was always like this -- release memory in the dtor.

| Currently we have to manage this business manually, which will leads to
| problems.

"We" as in class implementers/authors, or "we" as users?   As authors, yes we
do have to manage this, but that is because R forces us to, no?

| So i propose that RObject::m_sexp becomes private (as opposed to
| protected) and we had a protected setSEXP that :
| - release the current SEXP if there is one
| - preserve the new SEXP
|
| and make preserve and release protected (maybe even private members of
| RObject), and remove the preserved bool.

Sounds like a technically more sounds implementation, but nothing really
changes for the user, no?  Ie there never was a user-accessibly method to
unprotect/unpreserve.

This is currently accesible: preserve, release, isPreserved and 
forgetPreserve are public member functions of RObject, that the user 
needs to use, because I did not get R_PreserveObject/ R_ReleaseObject 
right. see the documentation in RObject.h for these.

I'll hide them and work them out automatically.

Probably not until tonight, but we should release anyway. this is a 
subtle problem.

Am I missing something?

Dirk

Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/IW9B : C++ exceptions at the R level
|- http://tr.im/IlMh : CPP package: exposing C++ objects
`- http://tr.im/HlX9 : new package : bibtex