[C++-sig] Re: C arrays mk 2

[David Abrahams]

Raoul Gough wrote:

> David Abrahams <dave at boost-consulting.com> writes:
> 
> 
>>Raoul Gough wrote:
> 
> [snip]
> 
>>>>Right, and because it's not, fundamentally, a pair of iterators.  It's
>>>>a facade for the Container concept.
>>>
>>>OK, yes, it provides *part* of the container interface, since it has
>>>the typedefs and begin() and end() and some syntactic niceities like
>>>operator[]. However, there is an important distinction in terms of
>>>storage management as I already mentioned. From the way you described
>>>it, calling something std::list would be wrong, because that's an
>>>implementation detail.
>>
>>No, it's not.  Its list-ness affects externally visible properties
>>like complexity of insert, iterator invalidation, etc.  If you can
>>build something with the same properties using a different data
>>structure, by all means go ahead and call it "list".
> 
> 
> OK, but apply the same reasoning to "iterator_pair" and there is no
> problem with that name either. The iterator-pairness of my container
> affects important semantic properties, mainly the fact that it
> references external objects. e.g.
> 
> int a[10] = { 0 };
> &iterator_pair<int *>(a, a + 10)[0] == a

Nothing about its interface exposes its pairness or the underlying 
iterators.  Can you ask it to increment its its first or last iterator? 
  At least with list the name tells you there's a sequence.

> This is an important property in terms of usefulness, but also in
> terms of object lifetime management, unless you want to risk having
> dangling references. For instance you need to consider what would
> happen if you have an iterator_pair that references the contents of a
> standard container - any operations on the container that invalidate
> iterators within the range will affect the iterator_pair.

There are too many other ways to realize that property.  Maybe "list" is 
badly named also; it's the only such example in the standard containers. 
  The tradition in container collections is to go with more-generic 
names like "bag".

But, enough of this; I don't believe in the name "iterator_pair" -- that 
should be reserved for something like pair<iterator,iterator> -- but if 
I can't convince you, so be it.

>>>Anyway, paragraph one of the container requirements says:
>>>  "Containers are objects that store other objects. They control
>>>  allocation and deallocation of these objects through constructors,
>>>  destructors, insert and erase operations."
>>>There is also no way that ~iterator_pair is going to "apply the
>>>destructor to every element", as is required of containers.
>>
>>OK, point taken.
>>
>>
>>>>>Also, I'm also not sure that it could really be called immutable,
>>>>>since you can replace elements (just not insert or delete them).
>>>>>Anyway, can you suggest an alternative name?
>>>>
>>>>container ;->
>>
>>Well, I'm stumped for a name at the moment.  I think we need a new
>>concept in the hierarchy, less-refined than Container.
> 
> 
> How about "iterator_pair" :-)

Yuck.

> Actually, I now think "iterator_range" might have been better

Yes.

> , because
> it hints that the two iterators must define a range. However, I can't
> conceive of any sensible implementation with similar semantics that
> *doesn't* store a pair of iterators, so I don't see anything to be
> gained by trying to hide this behind a new abstraction.

Ah, I just realized what the right name is:

      range_view

or, if you insist

      iterator_range_view

see http://www.zib.de/weiser/vtl/ for precedent.