[Rcpp-devel] inheritance

Richard Downe richard-downe at uiowa.edu
Wed Oct 5 19:22:44 CEST 2011


Thanks, I'll weigh my options going forward, but I appreciate seeing 
another approach.
--rd

On 10/05/2011 08:54 AM, Douglas Bates wrote:
> On Wed, Oct 5, 2011 at 8:51 AM, Douglas Bates<bates at stat.wisc.edu>  wrote:
>> On Tue, Oct 4, 2011 at 11:14 PM, Dirk Eddelbuettel<edd at debian.org>  wrote:
>>> On 4 October 2011 at 19:53, Richard Downe wrote:
>>> | Since I'm a bit of a glutton for punishment, and I would like to see
>>> | this feature...are there major technical hurdles as to why this has not
>>> | been implemented (e.g., I should just give up and find another way), or
>>> | is it more just a "nobody's gotten around to it because it's good enough
>>> | how it is", where I might be able to change the situation?
>>>
>>> "Health warning: Template meta-programming may make your head explode."
>>>
>>> It is mostly "just really hard". Try to find the old posts by Romain and go
>>> from there.
>>>
>>> We all would like the feature, but it takes some determination so make it
>>> happen. So far Romain has pretty much pushed the Rcpp modules implementation
>>> all by himself.
>> Essentially this is why I decided to skip using Rcpp modules in the
>> lme4Eigen package and roll my own interface from R reference classes
>> to C++ classes using external pointers explicitly.  I couldn't work
>> out how to avoid defining explicit methods for every C++ class even if
>> there is already such a method defined for the parent class. See the
>> files lme4Eigen/R/AllClass.R and lme4Eigen/src/external.cpp to see a
>> version using explicit external pointers (the lme4Eigen package is
>> only available from http://R-forge.R-project.org/web/packages/lme4 -
>> it is not yet on CRAN).
> Sorry, that link is wrong.  It should be
> http://R-forge.R-project.org/packages/lme4
>
> I mixed up the naming scheme on CRAN with the one of R-forge.
>
>> Another subtle issue arises when using Rcpp modules, which is the
>> ability to save an object to a file and then load it in another
>> session.  Essentially you can't.  The object depends on external
>> pointers for its functionality and the external pointers are not
>> saved.  When you load or attach such a saved object (as in save(foo,
>> file="foo.rda"); rm(foo); load("foo.rda")) it is, in Ron Zeigler's
>> famous words, "no longer operative".
>>
>> To overcome this I create explicit and implicit versions of the
>> information needed to reconstruct the C++ object.  So an lmResp
>> reference class has numeric fields "Y", "Offset", "Weights" and "Ptr"
>> plus activeBindingFunction fields "y", "offset", "weigths" and "ptr".
>> All methods are defined using "ptr" which returns Ptr if it is not
>> null and reconstructs it then returns the new value if it is a null
>> pointer.  (Don't confuse a null external pointer with the R object
>> NULL.  The null external pointer is an external pointer object which
>> points to the memory address 0.)
>>
>>
>>
>>> Dirk
>>>
>>> --
>>> New Rcpp master class for R and C++ integration is scheduled for
>>> San Francisco (Oct 8), more details / reg.info available at
>>> http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php
>>> _______________________________________________
>>> Rcpp-devel mailing list
>>> Rcpp-devel at lists.r-forge.r-project.org
>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>>>



More information about the Rcpp-devel mailing list