Subject: Re: [boost] Dereferencing End Iterators (Was: Performance Tuning?)
From: Edward Grace (ej.grace_at_[hidden])
Date: 2009-07-22 10:49:47
[ We're probably in danger of irritating other people if we continue
this discussion too long let's try and keep it brief].
>> My second gripe is that even the idea of undefined behaviour is
>> inconsistent (in MSVC at least). I can quite happily iterate
>> something to .end() (one past the last element) but not to
>> .end()+n --- why?
> Because dereferencing an end iterator has undefined behavior.
The above was a slip of the finger. I agree with you regarding
the .end() + n. I should have based it on .begin() which was the
original source of my iteration.
A concrete example of what I'm talking about is here:
I assert that the problem is that the bounds checking in MSVC is
wrong - it should only be checking for the de-referencing of invalid
iterators not their creation.
What do you think?
>> From what I can see this prevents the simple creation of a
>> striding iterator, for which the .end() can be at .end() +
>> stride of the underlying vector. One can do it easily by
>> default in g++ as it doesn't hold your hand (exposing you to
>> dereferincing this as being undefined) and leaving that up to
>> you. In MSVC8 it will barf since the debug bounds checking
>> doesn't allow you to keep iterating past the end.
> The debug bounds checking is revealing that you are relying on
> undefined behavior.
I may be in practice - but I don't think I am in principle.
>> Which is the correct treatment?
> Perhaps you're unfamiliar with the phrase "undefined behavior."
It's occasionally been used to describe the conduct of some friends
> If it isn't clear by now, don't dereference an end iterator and
> don't try to dereference anything past it.
I don't think I am -- that's my point.
Ultimately are random access iterators *supposed* to be homeomorphic
to the integers in the same (apparent) way C indices are?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk