Re: Bug in my code or compiler?

From: Gary Labowitz (
Date: 05/26/04

Date: Tue, 25 May 2004 23:31:44 -0400

"Leor Zolman" <> wrote in message
> On Tue, 25 May 2004 14:42:19 -0400, "Gary Labowitz"
> wrote:
> >"Leor Zolman" <> wrote in message
> >
> >> On Tue, 25 May 2004 09:39:27 -0400, Garrett Kajmowicz
> >> <> wrote:
> >>
> >> >I am trying to find out if this is a bug in my code or the compiler.
> >> >it is the compiler, I will notify the GCC people.
> >>
> >> I'd say: your code.
> >> Now let me look at it ;-)
> >>
> >> >
> >> >iter = currentStates.end();
> >> >
> >> >if(iter->getCurrentCost() > 20000){
> >>
> >> Right there. An "end" iterator is really a "past the end" iterator.
> >> you're not allowed to de-reference it. If you want an iterator to the
> >> element, make sure your container isn't empty and then decrement the
> >> iterator you get from end().
> >
> >This kind of error would be better understood if one thinks of the
> >as pointing before the element that will next be retrieved.
> >I adopted this way of thinking for a number of location types, like
> >start and end parameters, etc. I learned it from Java.
> I'm not sure what to think. Iterators are "restricted, generalized
> pointers" (Scott Meyers' wording), so if it makes sense to see an iterator
> as pointing before the element, it ought to make equal sense to see
> pointers as pointing "before the object".
> Pointers are used to point to individual objects (not in an array or
> vector, say) more often than iterators are (I guess that's why they're
> called "iterators" and not "stlpointers" or something). But would it make
> sense to think of a pointer to an individual object as pointing "before"
> the object? I don't know, but I suspect that would cause more confusion
> than your suggestion re. thinking about iterators could save.

Hmmm.. this brings up a point I stuggle with. When you say "pointers point
to ..." I feel like objecting. I would rather say "pointers contain the
address of ..." This has got to be more accurate. As I understand it, when
an iterator advances it makes current the element it advances over, but
actually points past it to the next element that will be returned. That is
why if you use a current element, then retreat one element (advance minus),
then use the current element you get the same element both times. If you
think of the iterator "pointing" to the element, this sequence could lead
you to believe you will use the previous element to the one you used the
first time. If this isn't true I'll have to go back to reading.