<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Dirk,<div class=""><br class=""></div><div class="">Thanks for clarifying. I love the QuantLib package, I used while I was working in quant finance before moving to data science.</div><div class=""><br class=""></div><div class="">The idea behind my code is that I want to create a C++ backend to the GeneralTree package I recently committed on CRAN (<a href="https://cran.r-project.org/web/packages/GeneralTree/index.html" class="">https://cran.r-project.org/web/packages/GeneralTree/index.html</a> ). I have two goals:</div><div class="">1. provide a fast and unified interface to xml, JSON, YAML parsers. </div><div class="">2. provide a easy way to handle different models based on the same data using decision rules in the tree</div><div class=""><br class=""></div><div class="">The reason I want to write the backend in C++ is because R6 objects are slow. I initially wanted to keep objects by reference to prevent data.frames or entire models to be copied, which could be more important in case 2 than 1. What is your thought on this?</div><div class=""><br class=""></div><div class="">I could rewrite all the shared_ptr to XPtr to make sure the entire memory is managed by R instead of a mixture model. But if you think copies are better I might choose that approach.</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">Anton</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 6 Oct 2016, at 12:31, Dirk Eddelbuettel <<a href="mailto:edd@debian.org" class="">edd@debian.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">Hi Anton,<br class=""><br class="">Thanks for posting here.<br class=""><br class="">On 6 October 2016 at 10:52, Anton Bossenbroek wrote:<br class="">| I want to add a large number of objects in C++ that are managed by `shared_ptr` in a `vector`. However, when I push the limits of the amount that I want to allocate the data in R becomes inconsistent.<br class=""><br class="">A bit of background.<br class=""><br class="">Rcpp exists because of the excellent idea (by Dominick, around 2004 to 2005)<br class="">that using C++ templates for SEXP++ would make interfacing QuantLib easier in<br class="">the RQuantLib package I had started a few years earlier.<br class=""><br class="">QuantLib is a marvel. It started in the early 2000s and was the first project<br class="">I saw which has bet "big" on Boost testing, and, very importantly,<br class="">shared_ptr. QuantLib also makes extensive use of SWIG to govern interfaces<br class="">to (a large number of) other languages. And here is the key: None of those<br class="">can use shared_ptr objects. Neither does RQuantLib. Even though they are<br class="">pervasive in QuantLib.<br class=""><br class="">Now, we are here to interface R. All that Rcpp does, in essence, is making<br class="">it trivially easy to get objects in and out of R as proxy objects:<br class="">lightweight, no copy. And the memory _is still managed by R_. So that you<br class="">never need to use a SEXP directly in C++. That is a feature. [ Of course,<br class="">sometimes you need the SEXP as a quasi-variant type, but that is not the<br class="">common use. So let's just call it 'no SEXP in user code'. ]<br class=""><br class="">So I am not claiming that what you want to do here is impossible -- but I am<br class="">not aware of another project having done this: hold R objects in a smart_ptr.<br class=""><br class="">Also, you haven't really explained what you want to do, what the life cyle of your<br class="">objects is etc pp.<br class=""><br class="">At the simplest level, Rcpp use is synchronous: you call from R, pass some<br class="">content, do some calculations, report something back -- and everything<br class="">intermediary is destroyed. You can persist things, of course, when you<br class="">manage the memory. But you need to be very sure the things are then away<br class="">from R -- copies are probably best. XPtr objects are used in that context.<br class=""><br class="">Anyway, end of short speech. I would recommend you try to break you project<br class="">into smaller, more fundamental tasks. Maybe we can help with those, one by one.<br class=""><br class="">Dirk<br class=""><br class="">-- <br class=""><a href="http://dirk.eddelbuettel.com" 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></body></html>