On Wed, Feb 26, 2014 at 1:48 PM, Thell Fowler <tbfowl...@gmail.com> wrote: > On Wed, Feb 26, 2014 at 12:56 PM, Thell Fowler <tbfowl...@gmail.com> wrote: >> On Wed, Feb 26, 2014 at 12:33 PM, Dirk Eddelbuettel <e...@debian.org> wrote: >>> >>> On 26 February 2014 at 12:26, Thell Fowler wrote: >>> | BTW - what was the fix/issue you tackled yesterday? Possibly any >>> relation? >>> >>> Unrelated, mostly, as it was a for loop with iterators using comparison >>> (wrongly) and arithmetic on the iterator object. In that case using >>> old-school indices worked more reliably. Somewhat related in the sense that >>> unnecessary complexity was added by trying to be clever via iterators. >>> >>> Here we don't know. It could be something in our backend, or it could be >>> your >>> code. >>> >>> Dirk >>> >>> -- >>> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com >> >> >> Good point regarding 'being clever' with the iterators. >> >> Here's a small reproducible sample of without _anything_ else going on... >> >> https://gist.github.com/Thell/9231866 >>
--->8--- > > Narrowed down to invalidation of pointer because data (vec) is moved > _after_ the constructor exits. Setting the iterator member after the > construction has completed looks to resolve the issue. > > So, construct, { init, use }... > > Is that change of address on purpose to facilitate the Rcpp/R bridge > or is it a side effect? > > -- > Sincerely, > Thell I just wanted to report that if the std::vector<int> vectors are changed to IntegerVector vectors the addresses reported in BadIter do not change when the constructor completes. -- Sincerely, Thell _______________________________________________ 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