Re: [Boost-users] [boost] [multi_array] Everyone, please make your value-types Assignable!

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-17 22:32:35

on Thu Jul 17 2008, Daryle Walker <darylew-AT-hotmail.com> wrote:

> On Jul 17, 2008, at 3:19 PM, Ronald Garcia wrote:
>
>> On Jul 11, 2008, at 6:17 AM, Dr Johann A. Briffa wrote:
>>
>>> I realize this topic has been discussed before (I've seen at least
>>> a thread in 2006 and another in 2007), but I believe there is more
>>> to add. At issue is the decision that multi_array objects cannot
>>> be assigned [with the operator=() that is] unless the target is
>>> already the same size as the source. Further, there is no
>>> documented way to easily resize an existing array to the same size
>>> and range as some other array.
>>
>> Indeed there is no built-in way to easily resize a multi_array to be
>> the same size as another multi_array.  While there is no resize
>> member function that takes a pointer, there is one that takes a
>> model of the Collection concept (classes like boost::array and
>> std::vector are concepts).  Based on this interface, here is a stop- 
>> gap non-invasive solution that can resize a multi_array based on
>> another model of  MultiArray (multi_array, multi_array_ref, etc.):
> [TRUNCATE]
>
> Let's define some stuff here:
> T: some type you created, probably a class type
> a: an object of type T; it's valid, i.e. meets its invariants
> b: another object of type T, also valid; any similarities or
> differences in its state from a's state is unspecified
> C: the set of all valid states an object of type T may have
>
> Let function F: x -> Y, map a T object state x to a (sub)set of C
> named Y.  This function returns the subset of source states that a
> given state can receive during an assignment.
>
> If there exists at least one x in C such that F(x) = Y < C, then type
> T is _NOT_ Assignable!  In other words, the number of assignment- 
> compatibility classes in T must be exactly one for T to be Assignable.

Then, if I understand you correctly, none of the built-in types are
Assignable.

        char* p;     // p is unintialized
        char* q = p; // invalid

Yes, uninitialized is one of the valid states for a builtin type,
i.e. part of the type's invariants.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com