Boost logo

Boost :

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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at