[Rcpp-devel] pass-by-reference for reference objects

[Greg Minshall]

hi.  a little more on this same subject.

let's say one RCPP_EXPORT_CLASS's two classes: a and b, and let's say
that b contains some number of a's (as std::vector<a>, say).

then, the following appear to be true:

1.  if you pass one of the a's from a b object to a method of a, the
a object is *copied* before being invoked.  so, any changes to the a
object are not visible in the b object's copy of the a object.

2.  if you *return* a pointer to an a object from a C++ function, R will
decide that it owns the object, and, if the R code subsequently deletes
the reference to the object, it will be eligible for garbage
collection.  so, if a method of the b class returns one of the a objects
sitting inside it, R will likely decide to garbage collect memory that
it shouldn't ought to.  this will likely result in a crash.

the (too verbosely commented) test case below demonstrates this,
focusing on number 2, but with a slight aside in the direction of number
1.

as i mention in the test case, i suspect the R reference class
philosophy is that the unit of sharing is what is returned by a new(),
and even if that has things inside it that look exactly like things
outside it which themselves *are* shared (since they were returned by
their own, "more specific", new) the things inside are *not* shared when
used as parameters.

(i suppose a possible rule -- i suppose this with *no* clue as to
implementation -- would be like with C/C++, i.e., that a pointer, and/or
maybe a reference, indicates sharing, though only for cases where
sharing is legal, i.e., reference objects; maybe other objects with a *
or an & would result in a compile-time error?)

cheers, Greg
----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test7.cc
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130309/e2835807/attachment.ksh>