<div dir="ltr"><div dir="ltr">Ok, I think I got the idea. <div><br></div><div>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><br></div><div>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">https://github.com/<wbr>QuantStack/xtensor-r/blob/<wbr>master/inst/include/xtensor-r/<wbr>rxarray.hpp#L145</a></div><div><br></div><div><div><font face="monospace, monospace">    const int vtype = traits::r_sexptype_traits<int><wbr>::rtype;</font></div><div><font face="monospace, monospace">    SEXP shape_sxp = Rf_allocVector(vtype, shape.size());</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">    int* r_shape = INTEGER(shape_sxp);</font></div><div>        // set shape values ... </div><div><span style="font-family:monospace,monospace">    m_sexp = Rf_allocArray(SXP, shape_sxp);</span><br></div><div><br></div><div>So afterwards, the idea would be to make a call to </div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Rcpp_PreserveObject(m_sexp);</font></div><div><font face="monospace, monospace"><br></font></div><div>right? And if the destructor of the object is called (and the object is owned from C++) we would just call </div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Rcpp_ReleaseObject(m_sexp);</font></div></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">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><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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"><div><font face="arial, helvetica, sans-serif">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"></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-06 16:27 GMT-07:00 Dirk Eddelbuettel <span dir="ltr"><<a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 6 June 2017 at 17:06, Dirk Eddelbuettel wrote:<br>
| The general idea when working with R objects is that<br>
|<br>
|   -- on the way in from R to the C++ functions we construct object such that<br>
|      the existing memory (from R) is used; one example is how RcppArmadillo<br>
|      uses the 'advanced' constructors of Armadillo allowing to operate<br>
|      without copies; hence R managed memory is used while C++ functions are<br>
|      called; in general this side of the conversion is the templates as<>()<br>
|      converters;<br>
|<br>
|   -- on the way back we use the *alloc functions from the C-level API of R to<br>
|      construct objects that use memory from R's pool, once we return these<br>
|      objects to R as SEXP they are indistinguishable to R from its own; these<br>
|      are the wrap() functions (and I think we may make on occassion make "one<br>
|      final copy" at his level, but I'd have to double-check).<br>
<br>
</span>Actually, let me rephrase: "in most cases not involving native R types" do we<br>
make one copy at the return.<br>
<br>
The general approach is iterator based, see internal/wrap.h. But there is a<br>
lot of template magic...<br>
<br>
Dirk<br>
<span class=""><br>
| I haven't had a chance to look at what Wes is doing with Apache Arrow, and<br>
| what is happening with xtensor -- so thanks for getting the ball rolling.<br>
|<br>
| Dirk<br>
|<br>
| --<br>
| <a href="http://dirk.eddelbuettel.com" rel="noreferrer" target="_blank">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org">edd@debian.org</a><br>
</span>| ______________________________<wbr>_________________<br>
| Rcpp-devel mailing list<br>
| <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-<wbr>project.org</a><br>
| <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" rel="noreferrer" target="_blank">https://lists.r-forge.r-<wbr>project.org/cgi-bin/mailman/<wbr>listinfo/rcpp-devel</a><br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
<a href="http://dirk.eddelbuettel.com" rel="noreferrer" target="_blank">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org">edd@debian.org</a><br>
</div></div></blockquote></div><br></div>