Re: A class template for an N-dimensional generic resizable array

From: Gavin Collings (gcollings_at_[hidden])
Date: 2000-12-04 12:42:45

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> I don't understand why a begin_all and an end_all returning an all-
> element would present such a problem.

It isn't a problem.  (Unless, maybe, you've written some generic code 
that acts on containers and assumes the names begin / end, but that's 
probably not very common).

My point is merely that there is a trade off to be made and there's 
more than one way to make it.  We're really only talking about syntax 
and what the default view of the container should be when used with 
STL.

The argument is that 1) STL is fundamentally 1-D and 2) When using an 
STL algorithm, it is probably more common to want to view it as a 1-D 
element container rather than as an 1-D N-1 array container.  And 
that this leads to (resolvable) conflicts through operator[].

> The problem is not with operator[], it is with begin and end, which 
> is easily solved.

Your own starting point is that the meaning of operator[] is 
paramount and that, through the random access container requirements, 
all STL usage should be defined to be consistent.

> I think Beman mentioned that the class should be kept as simple as
> possible, Messing up operator[] just to allow begin and end to 
> iterate over all seems not to be simple, whereas adding specially 
> named begin and end functions for the purpose does.

I'm not sure that much complexity would be added by this.  
Overloading operator[] isn't a big deal; ambiguity can be avoided.  
Maybe you mean the associated types involved in supporting two kinds 
of iterators?  But these must be present to support begin() and 
begin_all().  And operator[] can be trivially implemented in terms of 
the associated underlying iterators.  It's really just about 
producing syntactic sugar to conform to STL's way of doing things.

Gavin