Boost logo

Boost :

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-12-04 17:19:51

In message <90gl2l+ctkf_at_[hidden]>, Gavin Collings
<gcollings_at_[hidden]> writes
>--- 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).

Nor very generic ;-)

>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

I think it would be a fairer characterisation to say that STL is one D
at a time, which swings the pendulum the other way.

>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[].

I think if we are looking to the STL or the built-in array model for
guidance, the set of requirements seems fairly clear on this. In
particular how N-dimensional cases are already handled by aggregation,

        vector< vector<T> >

But I agree that a straight run through all elements is important.
Rather than conflict with STL requirements, it seems easy enough to add
rather than mutate features.

>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.

Close. My own starting point is that the STL requirements are paramount,
and that consistency is an important design principle.

>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.

If I understand you correctly, this refers to the idea of having two
versions of operator[]? This adds a little to the implementation, but
IMHO complicates the class interface, which is currently a good and
clear one.



  Kevlin Henney phone: +44 117 942 2990
  Curbralan Limited mobile: +44 7801 073 508
  mailto:kevlin_at_[hidden] fax: +44 870 052 2289

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