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

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 
>STL.
>
>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,
eg

        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.

Thoughts?

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________