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
>
> Output::
>
>> # Via Rcpp
>> rcpp_BadIter(1)
> Initializing:
> state.begin addr: 0x1d96b70
> state_iter addr: 0x1d96b70
> Accessing:
> state.begin addr: 0x1d96b70
> state_iter addr: 0x1d96b70
>
>> # Via R
>> bi <- make_BadIter(1)
> Initializing:
> state.begin addr: 0x24225d0
> state_iter addr: 0x24225d0
>
>> bi$access( )
> Accessing:
> state.begin addr: 0x4108c70
> state_iter addr: 0x24225d0
> [1] 0
>
> It looks like it is on the back-end to me...
>
> --
> Sincerely,
> Thell
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
_______________________________________________
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
