Re: [Boost-users] Re: Iterators and maps [was Re: Where should STLsuggestionsgo?]

From: Jim Lear (jim.lear_at_[hidden])
Date: 2004-12-14 17:56:17

Ben Hutchings wrote:
 
> No, but I think your
> concept of what an iterator is may be faulty.  Since an iterator "points"
> to a sequence element (or to the end of a  sequence) by itself; there is
> no need to combine it with a container to  access that element.  You seem
> to want a regularity which doesn't really  make sense, hence my earlier guess
> that you wanted to write container-  independent code.   
>   
 Most of my concepts are definitely faulty (ask my wife), but they're especially
so when it comes to iterators!  :-)

I read the suggested interview with Stepanov, and it (along with everyone's
comments) was quite helpful.  But, my ignorance runs deep and wide.  My new
(mis-?) understanding of the iterator is that it allows generic programming
by providing a consistent interface to containers.  As such, Stepanov did
not want to understand the container to write an algorithm, but only the
iterator and operations on iterators.  Is my ignorance getting any narrower?
:-)

So, I'm guessing the pointer semantics were chosen to allow the iterator
to be completely separated from the container.  No need to pass the container
around when one can just use the iterators.  If the container[iterator] semantics
were chosen for accessing the data within a container, the iterator would
no longer be independent.  Hence the previous comment by David Abrahams,
"why should the map get involved in that operation at all when you can do
it all with the iterator?"

I think the light is beginning to turn on, but don't get your hopes up too
much. Iterators are very heavy concepts for newbies.  The concept of containers
aren't nearly so difficult, especially when coming from other languages that
have vectors, maps, etc.  Newbies (ahem, or maybe just me) automatically
jump to the containers and want to start using it (yes, I admit it, I wanted
to write code before reading the entire reference manual).  They look and
act just like they do in other languages, *except* when one wants to iterate
through them.  When encountering the Iterator reference page, my eyes glazed
over when I encountered "Iterators are in fact not a single concept, but
six concepts that form a hierarchy".  Zzzzz.  I just want to sequentially
access the contents of my map!  Why do I have to wade through a dozen pages
on iterators (and still not understand generic programming)?  Throw us newbies
a lifeline, please!  :-)

But let me anticipate the response.  :-) "Jim, you ignorant slu+, the iterator
is a new programming paradigm that allows one to write -- without even thinking
(except, perhaps, in *your* case) -- code that is container independent.
 If you don't know iterators, you don't know STL.  Learn it, love it, and
get over it."

Okay, okay! But I'm still pretty clueless because one of Ben's earlier statements
still doesn't digest yet:
> Container-independent code is an impossible and pointless goal. 
> maps  have different semantics from other containers.  <snip> What
> you can do  is to write iterator-independent code, then use an iterator adapter
> to  convert the iterators over pairs into iterators over the mapped values: 
>   
I thought the idea of generic programming is to make container-independent
code.  I'm not sure what an iterator adapter is, but is it necessary for
"iterator-independent code?"  I'm just a newbie who wants to sequence through
my map, really.  I don't want to be forced to understand iterators, adapters,
iterator-independence, and generic programing paradigms to do so.  :-)

<stupidity>
  My new slogans will be

    "no iterators for the ignorant!"
    "free map operators[]!"
    "bypass the iterators!"
    "ignorants unite!"
    "let stupid people program, too!"

</stupidity>  :-)
-- 
Jim Lear