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
_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel