Boost logo

Boost :

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

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