Ok, I think I got the idea. In the R->xtensor bindings, we always work directly on memory allocated through R (either passed in from R or allocated from C++ code).
The review-relevant lines are really only ~10 lines: https://github.com/ QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/rxarray.hpp#L145 const int vtype = traits::r_sexptype_traits<int>::rtype; SEXP shape_sxp = Rf_allocVector(vtype, shape.size()); int* r_shape = INTEGER(shape_sxp); // set shape values ... m_sexp = Rf_allocArray(SXP, shape_sxp); So afterwards, the idea would be to make a call to Rcpp_PreserveObject(m_sexp); right? And if the destructor of the object is called (and the object is owned from C++) we would just call Rcpp_ReleaseObject(m_sexp); And the memory is going to be freed again, at some point. And calling Rcpp_ReleaseObject(m_sexp) would also clear the shape_sxp "attribute", right? Thanks for your reply! Wolf 2017-06-06 16:27 GMT-07:00 Dirk Eddelbuettel <e...@debian.org>: > > On 6 June 2017 at 17:06, Dirk Eddelbuettel wrote: > | The general idea when working with R objects is that > | > | -- on the way in from R to the C++ functions we construct object such > that > | the existing memory (from R) is used; one example is how > RcppArmadillo > | uses the 'advanced' constructors of Armadillo allowing to operate > | without copies; hence R managed memory is used while C++ functions > are > | called; in general this side of the conversion is the templates > as<>() > | converters; > | > | -- on the way back we use the *alloc functions from the C-level API of > R to > | construct objects that use memory from R's pool, once we return > these > | objects to R as SEXP they are indistinguishable to R from its own; > these > | are the wrap() functions (and I think we may make on occassion make > "one > | final copy" at his level, but I'd have to double-check). > > Actually, let me rephrase: "in most cases not involving native R types" do > we > make one copy at the return. > > The general approach is iterator based, see internal/wrap.h. But there is a > lot of template magic... > > Dirk > > | I haven't had a chance to look at what Wes is doing with Apache Arrow, > and > | what is happening with xtensor -- so thanks for getting the ball rolling. > | > | Dirk > | > | -- > | http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > | _______________________________________________ > | Rcpp-devel mailing list > | Rcpp-devel@lists.r-forge.r-project.org > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel