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

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-12-04 10:03:22

In message <90g6dr+17nb_at_[hidden]>, Gavin Collings
<gcollings_at_[hidden]> writes
>The requirement to iterate over all elements shouldn't be 
>underestimated; from my own experience I've been through situations 
>where I've made similar choices to the one you are discussing only 
>later to reverse them after realising just how often I wanted to 
>iterate over all elements.  Therefore, I'm a little hesitant about 
>dropping it as the default behaviour.

I don't understand why a begin_all and an end_all returning an all-
element would present such a problem.

>But what of the problematic operator[]?  

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

>Even if we do this, though, we now have counter-intuitive indexing 
>behaviour.  One way around this is to have size() return an 
>array_size_type and then overload operator[] -
>
>   operator[]( array_size_type ) returns elements to conform to STL
>   operator[]( int )             returns sub arrays.
>
>With luck, array_size_type indexing could map directly to an integer 
>offset and bypass the multidimensional sub structure in the data (in 
>other words, be fast).
>
>I'm sure that other views of the container can be most elegantly 
>represented by adapters (like SubArray/RefArray) passing the 
>container around by reference.  Perhaps a general function slice( 
>dimensions ) is what's needed?
>
>Thoughts anyone?

Beware valarray ;-)

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. As you said yourself, there is a
lot of counter-intuition in what you are proposing.

Just my $0.02.

Kevlin
____________________________________________________________

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