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

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-12-06 13:05:49

In message <003901c05fa0$23f097b0$460a10ac_at_[hidden]>, Kris Thielemans
<kris.thielemans_at_[hidden]> writes
>I'll first have to look more closely at the current proposal. Is there any
>more recent source code than the CUJ paper?
>Or a summary of current changes/proposals?

If you look under multi_array in the boost files section on eGroups
you'll find a version dated the 2nd.

>> >- I allow indices with non-zero offset
>>
>> For any particular reason?
>
>just to have more natural index values in our application. For instance, the
>centre of an image is represented by indices [0][0].
>As I use pointers everywhere, it was painless to add, and doesn't influence
>performance.

What are the semantics of resize?

>> >- there is some extra code like operator+ etc and (binary) IO (but that's
>> >pretty trivial to add).
>>
>> What do you do for the ragged cases with operator+, ie where you add two
>> arrays together and a position is filled in one but not the other? Given
>> the different possibilities, I'm inclined to think of these options as
>> expressed through separate algorithm functions rather than a single
>> operator+.
>
>Not sure if I understand this. Just as in the standard case, you're supposed
>to add only arrays of the same index range. Otherwise, you're more thinking
>about a sparse representation. No?

I was just trying to clarify the semantics, in other words, whether they
uniquely obvious. My personal feeling is that operator+ does not belong
as part of the default interface at all.

Kevlin
____________________________________________________________

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