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.