Re: [boost] [UUID] PODness Revisited

Subject: Re: [boost] [UUID] PODness Revisited
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-26 05:36:55

>> class NonAggregateFoo { ... int int_; };
>>
>> is copied as efficiently as a raw 'int'. And NonAggregateFoo bunch[] can 
>> be
>> memcopied as well PODFoo bunch[] (I am not advocating that but simply
>> stating the fact).
>
> Your "fact" is wrong.
>
> 3.9/3: "For any POD type T, if two pointers to T point to distinct T
> objects obj1 and obj2, where neither obj1 nor obj2 is a base-class
> subobject, if the value of obj1 is copied into obj2, using the memcpy
> library function, obj2 shall subsequently hold the same value as
> obj1."
>
> That applies PODs only, and the other representation guarantees in
> [basic.types] also apply only to PODs.
>
> So using a "memcopied" NonAggregateFoo bunch[] invokes undefined
> behaviour, preventing its use in a standards-conforming library.

Actually my version of the standard draft (dated 2008-10-04) reads a bit 
differently "3.9/3. For any trivially copyable type T, if two pointers to T 
point to distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a 
base-class subobject, if the value of obj1 is copied into obj2, using the 
std::memcpy library function, obj2 shall subsequently hold the same value as 
obj1."

My statements above were with regard to Andy's non-POD uuid (although I am 
guilty of making my statement sound too generic). Andy's class seems to be 
"trivially copyable" (see 9/6 section for the definition). If so, then my 
"fact" is right and efficient copying of such uuids is covered by the 
Standard, well, a draft at the moment.

As for the rest, if the consensus is to go with POD, I am fine with it.

Best,
V.