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<[email protected]>  wrote:
On Tue, Oct 4, 2011 at 11:14 PM, Dirk Eddelbuettel<[email protected]>  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
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel


_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Reply via email to