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

From: Daryle Walker (darylew_at_[hidden])
Date: 2008-07-19 22:47:57

On Jul 18, 2008, at 8:03 AM, David Abrahams wrote:

> On Jul 18, 2008, at 7:30 AM, Daryle Walker <darylew_at_[hidden]>  
> wrote:
>>
[SNIP]
>> Yes, the OP was having a problem with a boost class (template)  
>> that is like std::valarray: you can only do assignments if the  
>> source and destination objects _already_ had the same layout.
>
> I understand that
>
>> And my first response to this thread explained why this is  
>> problematic for our users,
>
> I understand that too. My problem is with your implicit declaration  
> that such types are not to be considered Assignable.  That concept  
> is supposed to be compatible with the builtins.

My use of "Assignable" was more colloquial, and not one of the  
official meanings in various C++ literature.  What does practical  
assignability mean?  It means that any object of a certain type can  
be either initialized by or receive an assignment from any other  
valid object of that type (Uninitialized PODs can't count because a  
program that uses one as an r-value is illegal.) and the destination  
object becomes observationally identical to the source object.  If an  
object only lets certain objects of the same type be allowed to be  
assignment-source objects, then its utility becomes a lot lower  
because the user has to add more checks on his/her code.

It might be OK for a mixed-operation-assignment to discriminate (with  
either an assertion or exception) because there's no way to match two  
objects with incompatible parameters for the desired operation.  But  
the regular copy-assignment is different.  It has a special place in  
the C++ type/object model, so much so that said operator is  
automatically defined if it's not explicitly provided.  Anything that  
messes up the assumptions that C++ has about regular assignment, like  
multiple assignability classes or non-splatter semantics, cascades  
until an ugliness-hiding wrapper is made.
>>
>> and so we shouldn't do this.  In this setup, all objects are  
>> validly initialized; it's just there isn't a single assignment- 
>> compatibility class that all valid object states belong to.  Note  
>> that you have to go out of your way to create a class like this.
>
> Not really. It's pretty easy to end up with uninitialized members.  
> But that's really beside the point.
>
>>  It's a pain because the user who wants to use this class  
>> internally has either make sure all wrapping objects keep all sub- 
>> objects of this type within the same assignment-compatibility  
>> class or write a custom assignment routine.  Said routine can be  
>> at most the basic guarantee if the resizing or copy steps may throw.
>
> So?  I don't see how that's related or why it's a problem

It's an example of the hoops a user has to do if they need to  
"correct" the assignment on their end.  The problem is that the  
user's code doesn't have access to the inside information needed to  
increase the safety guarantee's strength.  If the author provided the  
assignment, s/he could have used the inside information to strengthen  
the safety guarantee.

>>  (A strong guarantee could be done if the type provides a swap  
>> that can cross assignment-compatibility classes.)  An author- 
>> supplied full-assignment routine could take advantage of the  
>> internal implementation and add rollback.
>

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com