[Rcpp-devel] Code review for xtensor R bindings

[Dirk Eddelbuettel]

On 6 June 2017 at 18:01, Wolf Vollprecht wrote:
| 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?

Yes, that is roughly correct and how we used to do things -- but you can
probably even do better by relying on

    Rcpp::Shield<yourTypeHere>

which then covers the preserve / release parts in its own ctor / dtor pair.

And I glanced at your repo, that looks pretty good so far. You found how to
declare C++14 as its default C++ standard, this of course requires R 3.4.0.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org