[Rcpp-devel] Wrapping a C struct in C++ for constructor/destructor
bates at stat.wisc.edu
Sat Dec 15 17:56:52 CET 2012
On Fri, Dec 14, 2012 at 12:07 PM, Richard Downe <richard-downe at uiowa.edu>wrote:
> Since cholmod has specific functions for all the allocation/free tasks
> involved in the different data structs, if you're really ambitious, you
> could probably create a templated mgr c++ class, where the template args
> are the specific memory management functions for the wrapped struct.
Perhaps I can continue this discussion with you off-list. I'm not sure
what you mean by an mgr C++ class but I am willing to learn.
One of the complications with the CHOLMOD memory-management model is the
assumption that all memory allocation and freeing is done by CHOLMOD
functions. So, for example, the cholmod_free_sparse function frees all the
arrays in the struct then frees the struct. We want to have the various
sparse matrices and Cholesky decompositions accessible from R. One could
accomplish this by always using cholmod_alloc_sparse, etc. and copying the
R object into the Cholmod-allocated storage and vice-versa but, considering
that many of these matrices are read-only and for complex models applied to
large data sets the single largest object is the Cholesky factor, that is
wasteful both in memory usage and in time.
Also, essentially every cholmod_* function takes a pointer to a
cholmod_common struct which is assumed to be global or at least consistent
throughout the series of calls in a problem solution. Maintaining a global
C struct like that through several .Call instances involves some dancing
around, especially if you want to modify members of the struct at the R
level. We had to do some rather messy manipulation in the Matrix package
to achieve this.
Then you could automagically generate ctor/dtor/copyctor/oper= code for
> each struct, and access the internal elements through a templated _ptr*
> member or something similar, and provide as()/wrap() specializations for
> the specific structs you wish to export to R.
Well at least this discussion has taught me what ctor, dtor etc. mean. I
have seen the names but hadn't looked them up to discover that ctor is an
abbreviation of constructor and dtor is an abbreviation of destructor.
> On 12/14/2012 10:43 AM, Romain Francois wrote:
>> I would create a class that contains a pointer to the c struct.
>> This obviously leaves the problem of freeing the memory, i.e does the c++
>> object own the pointer.
>> Maybe a strategy using some reference counting smart pointer.
>> In RcppEigen we have not resolved this, we simply exposed a free methid
>> for the class and the programmer has to call it. Not the best strategy
>> You could also prevent copy ctor and assignment op by making them private
>> without an implementation, and always pass them by reference. Then you can
>> consider that your c++ object owns the pointer.
>> Le 14 déc. 2012 à 17:10, Douglas Bates <bates at stat.wisc.edu> a écrit :
>> This is more a C++ question than an Rcpp question although, of course,
>>> the application will be through Rcpp.
>>> I want to use C functions defined in the CHOLMOD package using Rcpp.
>>> The arguments to these functions and the returned values are usually
>>> pointers to C structs. There are several such structs defined in CHOLMOD
>>> and it gets tedious to use code that allocates storage for the struct,
>>> populates the struct, uses it and then frees it. (If you look in the
>>> Matrix package sources you will see several inelegant utility functions and
>>> macros to perform these operations).
>>> For an Rcpp/C++ approach I would prefer to use constructors and
>>> destructors for the memory allocation and freeing. Is the recommended
>>> approach to create a C++ class or struct that extends the C struct or to
>>> create a C++ class with the C struct as a member of the class?
>>> I should be able to create the code for myself if I just know where to
>>> look for examples. I tried StackOverflow but I was unable to narrow down
>>> my search. Pointers to sections of "C++ Annotations" or to StackOverflow
>>> questions would be appreciated.
>>> Rcpp-devel mailing list
>>> Rcpp-devel at lists.r-forge.r-**project.org<Rcpp-devel at lists.r-forge.r-project.org>
>> Rcpp-devel mailing list
>> Rcpp-devel at lists.r-forge.r-**project.org<Rcpp-devel at lists.r-forge.r-project.org>
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-**project.org<Rcpp-devel at lists.r-forge.r-project.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rcpp-devel