Re: Missing in Booch: range operations

[mheaney@on2.com (Matthew Heaney)]

Simon Wright <simon@pushface.org> wrote in message news:<x7vznsizw0n.fsf@smaug.pushface.org>...
> mheaney@on2.com (Matthew Heaney) writes:
> 
> > The problem is that iterators only know about elements -- they don't
> > know anything about containers.  Neither Charles nor the STL attempts
> > to detect this error.
> 
> Matt, you say this as though it were a law of nature! There is nothing
> in the notion of iterator that prevents them knowing about the
> container. Indeed (being pedantic) the very name iterator indicates
> that there is a container involved (otherwise, what would you be
> iterating over?)

When I speak of an iterator, I am refering to what STL and Charles do.
 In that model, iterators don't know about containers.

Charles iterators are modelled on iteration thru a linked list, for
example:

  List : List_Type;

  declare
    Node : Node_Access := List.Head;
  begin
    while Node /= null loop
      <do something with Node.Element>
      Node := Node.Next;
    end loop;
  end;

In other words, the "iterator" Node_Access doesn't know anything about
the list object.  It only knows about the nodes in the list (and nodes
in the list don't know anything about the list, either).

Of course, it is possible to implement an iterator type as a "fat"
pointer, comprising a pointer to the internal node, and another
pointer to the container.  But this is not necessary in order to have
a working iterator, and it does incur a space penalty.

Charles has been optimized for flexibility and efficiency, and it is
general enough that such a layer (comprising a "fat" iterator) on top
of the existing infrastructure can be implemented quite easily.  As
much as possible I prefer to defer issues as this ("thin" vs. "fat"
iterators) to the library user.