[Rcpp-devel] Rcpp modules and return_value_policy for exposed C++ member functions

Claymore Marshall claymorejmarshall at gmail.com
Mon Nov 10 22:51:45 CET 2014


Thank you for the feedback Dirk.  Fair enough.

I think the issue I have is similar to this (I want to set  StoragePolicy =
false for the XPtr), so I sort of have a work around going:
*http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2013-February/005273.html
<http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2013-February/005273.html>*

I would like 'res' to be a 'non-owning' reference pointer in R to A in B.
I don't know how this could be done directly (or if it's possible) with a
.finalizer ... do you mind elaborating a little?  (The Rcpp module vignette
is very brief on .finalizer).  Or are there any examples anywhere that
demonstrate what you mean?

Thanks again.


On Mon, Nov 10, 2014 at 1:45 PM, Dirk Eddelbuettel <edd at debian.org> wrote:

>
> On 10 November 2014 at 13:16, Claymore Marshall wrote:
> | I want to expose to R several C++ classes from a library with Rcpp
> modules.
> | I'm trying to imitate a similar set of Python modules that were made for
> the
> | same library.
> |
> | In Boost.Python, with .def it is possible to specify the
> return_value_policy.
> | Is it also possible to do this in a straight forward way with Rcpp
> modules when
> | exposing C++ class methods?
> |
> | The following simplified example illustrates a problem I face with using
> Rcpp
> | modules.  When R deletes 'res', R crashes shortly after (a segfault?).
> |
> | With a Python module, this kind of problem apparently doesn't come about
> by
> | setting in .def the
> following: return_value_policy<reference_existing_object>()
> |
> |
> | Is there an easy way to get around this problem with Rcpp modules with
> minimal
> | code?
> |
> | #include <Rcpp.h>
> | using namespace Rcpp;
> |
> | class A {
> |
> |   public:
> |
> |     A(int x_) : x(x_){}
> |
> |     int x;
> | };
> |
> | class B {
> |
> |   public:
> |     B():m_A(10) {}
> |
> |     A get_an_A(){
> |       A an_A(3);
> |       return an_A;
> |     }
> |     A * get_member_A() { return & m_A; }
> |
> |   private:
> |     A m_A;
> | };
> |
> | RCPP_EXPOSED_CLASS(A)
> | RCPP_EXPOSED_CLASS(B)
> |
> | RCPP_MODULE(AB_mod){
> |   using namespace Rcpp ;
> |   class_<A>("A")
> |    .constructor<int>()
> |    .field("x", &A::x)
> |   ;
> |   class_<B>("B")
> |    .constructor()
> |    .method("get_an_A",&B::get_an_A)
> |    .method("get_member_A", &B::get_member_A)
> |   ;
> | }
> |
> |
> |
> | ------------------------
> |
> | R code:
> |
> | A_eg <- new(A, 10)
> | B_eg <- new(B)
> |
> | res <- B_eg$get_member_A()
> |
> | rm(res)
> | # R crashes shortly after running further commands ...
> | # How can this error be prevented?
>
> By not removing res?
>
> By adding a finalizer / destructor for it?
>
> I don't use modules for things I add / remove frequently from the heap. I
> generally just create an object "and keep it".  That usage works for me.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20141110/10d0e99f/attachment.html>


More information about the Rcpp-devel mailing list