On 06.06.2011, at 13:42, Romain Francois wrote:
> Le 04/06/11 16:31, soeren.vo...@uzh.ch a écrit :
>
>> FOO is the C++ object, and Foo should be the S4 class. If the user creates
>> an object, say bar, from class Foo, the creation process automatically makes
>> a new FOO object relating to bar in that a unique name of the FOO instance
>> is stored in a slot of bar. All the user then has to do is modify bar by
>> simple assignments. The getters and setters ("$", "[") are set up and work.
>> Each modification goes in hand with assigning new values to bar as well as
>> updating the FOO object through available setters from FOO.
>>
>> So far, this way has brought me to about 100 lines, but now I read about
>> ReferenceClasses and was wondering, if there is a much easier way of
>> achieving my goals. Moreover, I was not sure any longer if my goals make
>> sense or if a more advanced programmer would do it totally different (and
>> could share some structural thinking on their approach).
>>
>> The idea behind my way of doing was based upon several considerations.
>> First, a "classical" R object would not confuse users, as I assume users of
>> my package to be rather non-skilled (and not willing to change that).
>> Second, I want to create a properly programmed package for distribution on
>> CRAN and publication, eventually. Third, I want to save objects across
>> sessions. So if a user restores a session, a simple command, say, restore(),
>> would do the trick to build all the related C++ objects again. However, I
>> admit that I still have not figured out how to automatically clean up the
>> workspace correctly before leaving a session, wanted or unwanted, that is,
>> clean up memory before leaving home. Fourth, pure arithmetic check is done
>> in C++, however, semantic check *should* be left to R, and the validity and
>> class routines seem to be perfect for this. Fifth, some work should be done
>> in R, such as the passing of data frames or samples from distributions.
>
> Hello,
>
> A C++ class that is exposed through an Rcpp module is already a reference
> class, and so you can add methods, etc ...
>
> Consider this example :
>
> require(inline)
> require(Rcpp)
>
> fx <- cxxfunction( , '', includes = '
>
> class FOO{
> public:
> FOO( double x_, double y_): x(x_), y(y_){}
>
> double x ;
> double y ;
>
> void move( double dx, double dy){
> x += dx ;
> y += dy ;
> }
> } ;
>
> RCPP_MODULE(mod){
>
> class_<FOO>("FOO" )
>
> .constructor<double,double>()
>
> .field( "x", &FOO::x )
> .field( "y", &FOO::y )
>
> .method( "move", &FOO::move )
> ;
> }
>
>
> ', plugin = "Rcpp" )
> mod <- Module( "mod", getDynLib(fx),mustStart = TRUE )
>
> # grab the exposed C++ class
> FOO <- mod$FOO
>
> # add R methods
> FOO$methods(
> bla = function() x+y,
> reset = function() {
> x <<- 0.0
> y <<- 0.0
> }
> )
> # create an instance
> f <- new( FOO, 2.0, 3.0 )
>
> # call an R method
> f$reset()
>
> # call a C++ method
> f$move( 2.0, 2.0 )
>
> # call an R method
> f$bla()
Thanks Simon and Romain for your great help! That C++ classes exposed via
Rcpp-modules are already reference classes helps a lot and saves time for
unnecessary mirroring. According to Romain saving class objects across sessions
remains to be implemented in Rcpp. I have not browsed the rJava package
extensively, but I found serialize() (base) and this function seems to provide
a workaround. Yet, I do not know how to use it in practice with my package.
Some thoughts: consider the small FOO example below. Then, on accidental crash
or quit(save="yes"), or whatever users may do, R "should" know that it has to
serialise all existing FOO objects. Note, that in my package these objects are
"sort of lists" that can become quite large (say, a vector of 15,000 numeric
values plus a character string). After restoring a previously saved image, R
"should know" to load my package, and that in turn should deserialise every FOO
object present in the image. Sounds like a not too complicated task, something
like .dofirst()/.dolast() -- but that again exceeds my R and C++ programming
skills, and I hope that you experts may share an idea. Thanks, Sören
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
