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>
[Rcpp-devel] pass-by-reference for reference objects
1 message · Greg Minshall