From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-12-06 13:05:49
In message <003901c05fa0$23f097b0$460a10ac_at_[hidden]>, Kris Thielemans
>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 .
>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
>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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk