From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-12-04 17:19:51
In message <90gl2l+ctkf_at_[hidden]>, Gavin Collings
>--- 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
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk