[Rcpp-devel] Rcpp vector classes vs std::vector for custom class member variables
Jon Clayden
jon.clayden at gmail.com
Tue Oct 8 14:53:21 CEST 2013
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?
> 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.
> 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.
> 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... :)
Regards,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20131008/7586284a/attachment.html>
More information about the Rcpp-devel
mailing list