Re: Charles: missing vector iterators

[porton@ex-code.com (Victor Porton)]

In article <1ec946d1.0211140804.42621077@posting.google.com>,
	mheaney@on2.com (Matthew Heaney) writes:
> porton@ex-code.com (Victor Porton) wrote in message news:<3dd29387$0$303$bed64819@news.gradwell.net>...
>> Why in Charles.Vectors iterators are missing even despite it is 
>> modelled after STL?
> 
> Because iterators for vectors are too fragile.
> 
> An unbounded vector automatically grows as necessary during
> insertions.  This works by deallocating the existing internal array,
> reallocating a new (longer) array, and copying the existing elements
> onto the new array.
> 
> The issue is that an iterator designates the old array, which gets
> deallocated.  It's too easy for forget this fact, which means dangling
> references occur.

type Iterator_Type is private;

...

type Iterator_Type is
    record
        Contaner: Container_Access;
        Index: Index_Type;
    end record;

It is probably space inefficient but otherwise good.

With a good compiler we seemingly can even live without space 
inefficiency using my previously posted to c.l.a idea of per
container instance iterators:

type Iterator_Type(Contaner: Container_Access) is
    record
        Index: Index_Type;
    end record;

Now we can introduce a space efficient Range_Type (if compiler well 
optimized records with discriminants for space):

type Range_Type(Contaner: Container_Access) is
    record
        First, Last: Iterator_Type(Container);
    end record;

With a good compiler (if these exist) here it will be optimized to keep 
only one value of Container_Access for Range_Type variables.

Well, may be someday I will write my own containers library with 
features like this container-specific Range_Type.

BTW, for conveniency ranges should be transfered not as two separate
values, but as records with two components.

> The whole problem goes away by simply using the index subtype to refer
> to elements in the vector, instead of an iterator.

[Skipped because we define the term "iterator" differently:
 I mean fat iterators (which can be dereferenced without
 supplying containers; while Matthew Heaney means
 "something based on pointers".]