<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi, </div><div class=""><br class=""></div><div class="">Instead of doing that: </div><div class=""><br class=""></div><div class=""><div class="">const int vtype = traits::r_sexptype_traits<int>::rtype;</div><div class="">SEXP shape_sxp = Rf_allocVector(vtype, shape.size());</div></div><div class=""><br class=""></div><div class="">Perhaps your rxarray object could hold an IntegerVector. Also not quite sure why you use the first line at all, which does not depend on T, so vtype is always going to be INTSXP. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Also, you should avoid using std::cout in <a href="https://github.com/QuantStack/xtensor-r/blob/master/src/rcpp_hello_xtensor.cpp#L14" class="">https://github.com/QuantStack/xtensor-r/blob/master/src/rcpp_hello_xtensor.cpp#L14</a></div><div class=""><br class=""></div><div class="">You can use Rcpp::Rcout instead, or Rprintf. </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><font face="arial, helvetica, sans-serif" class="">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?</font></div></div></div></blockquote></div><div class=""><br class=""></div><div class="">The shape_sxp object you create here (and don’t protect)</div><div class=""><a href="https://github.com/QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/rxarray.hpp#L152" class="">https://github.com/QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/rxarray.hpp#L152</a></div><div class=""><br class=""></div><div class="">Is probably duplicated here: </div><div class=""><a href="https://github.com/QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/rxarray.hpp#L160" class="">https://github.com/QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/rxarray.hpp#L160</a></div><div class=""><br class=""></div><div class="">As part of allocArray’s business: </div><div class=""><a href="https://github.com/wch/r-source/blob/d60c742aa8acc764874db87e3c748e27986e1134/src/main/array.c#L259" class="">https://github.com/wch/r-source/blob/d60c742aa8acc764874db87e3c748e27986e1134/src/main/array.c#L259</a></div><div class=""><br class=""></div><div class="">Romain</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">Le 7 juin 2017 à 03:01, Wolf Vollprecht <<a href="mailto:w.vollprecht@gmail.com" class="">w.vollprecht@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">Ok, I think I got the idea. <div class=""><br class=""></div><div class="">In the R->xtensor bindings, we always work directly on memory allocated through R (either passed in from R or allocated from C++ code).</div><div class=""><br class=""></div><div class="">The review-relevant lines are really only ~10 lines: <a href="https://github.com/QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/rxarray.hpp#L145" target="_blank" class="">https://github.com/<wbr class="">QuantStack/xtensor-r/blob/<wbr class="">master/inst/include/xtensor-r/<wbr class="">rxarray.hpp#L145</a></div><div class=""><br class=""></div><div class=""><div class=""><font face="monospace, monospace" class=""> const int vtype = traits::r_sexptype_traits<int><wbr class="">::rtype;</font></div><div class=""><font face="monospace, monospace" class=""> SEXP shape_sxp = Rf_allocVector(vtype, shape.size());</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class=""> int* r_shape = INTEGER(shape_sxp);</font></div><div class=""> // set shape values ... </div><div class=""><span style="font-family:monospace,monospace" class=""> m_sexp = Rf_allocArray(SXP, shape_sxp);</span><br class=""></div><div class=""><br class=""></div><div class="">So afterwards, the idea would be to make a call to </div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class="">Rcpp_PreserveObject(m_sexp);</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class="">right? And if the destructor of the object is called (and the object is owned from C++) we would just call </div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class="">Rcpp_ReleaseObject(m_sexp);</font></div></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="arial, helvetica, sans-serif" class="">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?</font></div><div class=""><font face="arial, helvetica, sans-serif" class=""><br class=""></font></div><div class=""><font face="arial, helvetica, sans-serif" class="">Thanks for your reply! </font></div><div class="gmail-yj6qo gmail-ajU"><div id="gmail-:10n" class="gmail-ajR" tabindex="0"><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif" style="opacity: 0.3;"></div></div><span class="gmail-HOEnZb gmail-adL"><font color="#888888" class=""><div class=""><font face="arial, helvetica, sans-serif" class="">Wolf</font></div></font></span></div><div class="gmail-HOEnZb gmail-adL"><div class="gmail-adm"></div><div class="gmail-im"><div class="gmail_extra"><br style="font-size:12.8px" class=""></div></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2017-06-06 16:27 GMT-07:00 Dirk Eddelbuettel <span dir="ltr" class=""><<a href="mailto:edd@debian.org" target="_blank" class="">edd@debian.org</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
On 6 June 2017 at 17:06, Dirk Eddelbuettel wrote:<br class="">
| The general idea when working with R objects is that<br class="">
|<br class="">
| -- on the way in from R to the C++ functions we construct object such that<br class="">
| the existing memory (from R) is used; one example is how RcppArmadillo<br class="">
| uses the 'advanced' constructors of Armadillo allowing to operate<br class="">
| without copies; hence R managed memory is used while C++ functions are<br class="">
| called; in general this side of the conversion is the templates as<>()<br class="">
| converters;<br class="">
|<br class="">
| -- on the way back we use the *alloc functions from the C-level API of R to<br class="">
| construct objects that use memory from R's pool, once we return these<br class="">
| objects to R as SEXP they are indistinguishable to R from its own; these<br class="">
| are the wrap() functions (and I think we may make on occassion make "one<br class="">
| final copy" at his level, but I'd have to double-check).<br class="">
<br class="">
</span>Actually, let me rephrase: "in most cases not involving native R types" do we<br class="">
make one copy at the return.<br class="">
<br class="">
The general approach is iterator based, see internal/wrap.h. But there is a<br class="">
lot of template magic...<br class="">
<br class="">
Dirk<br class="">
<span class=""><br class="">
| I haven't had a chance to look at what Wes is doing with Apache Arrow, and<br class="">
| what is happening with xtensor -- so thanks for getting the ball rolling.<br class="">
|<br class="">
| Dirk<br class="">
|<br class="">
| --<br class="">
| <a href="http://dirk.eddelbuettel.com/" rel="noreferrer" target="_blank" class="">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org" class="">edd@debian.org</a><br class="">
</span>| ______________________________<wbr class="">_________________<br class="">
| Rcpp-devel mailing list<br class="">
| <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org" class="">Rcpp-devel@lists.r-forge.r-<wbr class="">project.org</a><br class="">
| <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" rel="noreferrer" target="_blank" class="">https://lists.r-forge.r-<wbr class="">project.org/cgi-bin/mailman/<wbr class="">listinfo/rcpp-devel</a><br class="">
<div class="HOEnZb"><div class="h5"><br class="">
--<br class="">
<a href="http://dirk.eddelbuettel.com/" rel="noreferrer" target="_blank" class="">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org" class="">edd@debian.org</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">Rcpp-devel mailing list<br class=""><a href="mailto:Rcpp-devel@lists.r-forge.r-project.org" class="">Rcpp-devel@lists.r-forge.r-project.org</a><br class="">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</div></blockquote></div><br class=""></body></html>