[Rcpp-devel] Fwd: Exposed class works within cpp func, bombs via module

[Thell Fowler]

On Wed, Feb 26, 2014 at 1:48 PM, Thell Fowler <tbfowler4 at gmail.com> wrote:
> On Wed, Feb 26, 2014 at 12:56 PM, Thell Fowler <tbfowler4 at gmail.com> wrote:
>> On Wed, Feb 26, 2014 at 12:33 PM, Dirk Eddelbuettel <edd at 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 | edd at 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