[Rcpp-devel] Rcpp vector classes vs std::vector for custom class member variables

[Romain Francois]

Le 08/10/13 14:53, Jon Clayden a écrit :
> Thanks Dirk and Romain for your helpful replies. To follow up briefly...
>
>         I'm defining a custom class, an object of which will need to survive
>         across various calls back and forth between R and C++, so I plan
>         to use
>         the XPtr class to wrap a pointer. My question is, what are the
>         advantages and disadvantages of using Rcpp vector classes (vs
>         std::vector) for member variables? To be more concrete, I mean
>
>         class Foo
>         {
>         private:
>             Rcpp::NumericVector bar;
>         }
>
>         vs
>
>         class Foo
>         {
>         private;
>             std::vector<double> bar;
>         }
>
>         Are there garbage collection issues when these live inside an
>         XPtr<Foo>?
>
>
>     No. An XPtr<Foo> will delete the object it points to, using Foo's
>     destructor when it goes out of scope.
>
>
> Sure. And the memory allocated to "bar" (if it's a NumericVector) will
> be protected from the garbage collector until the Foo object is deleted?

yes

>     I would argue against using external pointers directly when you can
>     use modules and experience more type safety than with direct
>     external pointers.
>
>     But these (using external pointers and using modules) only make
>     sense when you want to be able to hold a reference to your object at
>     the R level, do you ?
>
>
> I think I do... ;)  I need the object to hold state and not be
> deallocated between calls into the C++ code. I also want to allow for
> the possibility that multiple Foo objects exist, and are being operated
> on simultaneously. So holding a handle on the R side and passing it back
> to each C++ function that works with the object seems like the natural
> approach to me.

I'd strongly advise to consider using modules as the vessel for that 
sort of things.

This way, on the R side, you have something concrete instead of 
something opaque. R does not know what is inside an external pointer, 
but a module object, you have access to its fields, methods, etc ...

>         Are there speed advantages of std::vector<double> over
>         Rcpp::NumericVector for general use? Any input would be welcome.
>         Thanks
>         in advance.
>
>
>     This is premature optimization. What you want to ask yourself is
>     what are you going to do with "bar". If bar goes back and forth
>     between the C++ and the R side, then NumericVector is your best
>     candidate.
>
>
> Agreed, but it's a consideration. I fully accept that the choice depends
> on the particular application, as you and Dirk both said. I was just
> wondering what the baseline performance difference (if any) might be.

There is no such answer. It really depends on what you do with bar

>     If bar is something internal to your class, then std::vector<> is
>     fine and will give you a more complete interface, will grow
>     efficiently, etc ...
>
>     If you really want to have the best performing class for your
>     application, you need to measure it.
>
>     It is easy enough to make Foo a template and switch between the two
>     in benchmarking:
>
>     template <typename Container>
>     class Foo {
>
>     private:
>              Container bar ;
>     } ;
>
>     Foo< std::vector<double> > f1;
>     Foo< Rcpp::NumericVector > f2;
>
>
>         Great work on Rcpp, by the way. I've been hearing very good
>         things for
>         quite some time, but wasn't sure if it was worth dusting off my
>         slightly
>         rusty C++ for. Suffice to say I think it was. The API is very
>         clean and
>         returning to the standard R API will be painful...!
>
>
>     Great. You don't need expert knowledge of C++ for Rcpp to be useful.
>
>
> Sure, but I'm doing quite a bit in native code so there's little point
> in dropping competent C code for badly-written C++. Yes, I could mix
> them, but it's nice to be able to make the most of the tools available... :)

Sure. Refactoring existing C code into C++ is kind of hard, but writing 
new C++ code instead of new C code is easier. At least it is from my 
perspective.

-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30