Re: Bug in my code or compiler?

From: Leor Zolman (leor_at_bdsoft.com)
Date: 05/26/04 

Date: Wed, 26 May 2004 02:06:20 -0400

On Tue, 25 May 2004 23:31:44 -0400, "Gary Labowitz" <glabowitz@comcast.net>
wrote:

>>
>> 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.

Whoa. If you can't say "pointers point", then I'm afraid the sky would be
next to fall. Is nothing sacred? :-)

>I would rather say "pointers contain the address of ..."
>This has got to be more accurate.

Sorry, but those two are 100% equivalent to me, and I'd be hard-pressed to
admit to any conceivable distinction between them.

> 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.

Doesn't make any sense to me, unless you're perhaps thinking of /reverse/
iterators, which do have this quaint way of pointing past (in a
right-to-left sort of way) the element they're actually referring to. If
you doubt that regular iterators actually point to (or "contain the address
of" the first byte of) their logical element, just consider the fact that
vector iterators are often implemented as raw pointers...

>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.

Say, what? [Unless you're again dealing with reverse_iterators and getting
confused by some funky order of dereferencing, decrementing (or would it be
incrementing?), calling base(), and dereferencing again...OR you've
assigned a different meaning to "retreat" and "advance minus" than the way
I interpret it: as "decrement the iterator"]:

#include <iostream>
#include <vector>
using std::cout;
using std::endl;

int main()
{
    using std::vector;
    
    int i[] = {1,2,3};
    vector<int> vi(&i[0], &i[3]);

    vector<int>::iterator it = vi.begin() + 1;
    cout << "*it = " << *it << endl;
    --it;
    cout << "after decrementing it, *it = " << *it << endl;

    return 0;
}

Output:
*it = 2
after decrementing it, *it = 1

(and I would have been really, REALLY surprised to see otherwise)

> 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.

It may be time to hit the books ;-)
        -leor 

-- 
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix  
C++ users: download BD Software's free STL Error Message Decryptor at:
   www.bdsoft.com/tools/stlfilt.html

Relevant Pages

  • Re: std::vector : begin, end and insert - Using Objects instead of ints
    ... vector< CPoint> vec; ... lists, which only have iterators. ... "overloaded pointers", and it is better to say that iterators are "an ... iterator approach to a loop. ...
    (microsoft.public.vc.mfc)
  • Re: arrays/vectors/templates
    ... Since you have designed your function to use iterators, ... beg and end types are not STL iterators) will cause a compile-time error ... You can make it work for pointers as well, however, using the ... std::iterator_traits template from the STL. ...
    (alt.comp.lang.learn.c-cpp)
  • abstract containers: does such a thing exist, conceptually?
    ... code implementing that pattern? ... behaviour by the additional pointers. ... trigger adding- or removing-operations of other iterators... ... 2)graph = list of lists: The same as above but with its own allocator ...
    (comp.object)
  • Re: Pointer To A Vector Elements While Still Adding
    ... No. list iterators (and you really should be using iterators, not pointers, ... Well that's a problem for vectors, but not for lists. ... lists do not (each node stores the address of the ...
    (comp.lang.cpp)
  • Re: Problem Based Passing Vectors Elements As Arguments
    ... > loop using the vector iterators. ... > Ok well fcalls another function, and i want to pass pointers to the ... > Well i know that the iterator class is basically just a pointer ... template<class ItX, class ItY> void f{ ...
    (comp.lang.cpp)
Loading