On 6/11/2014 12:22 AM, deadalnix wrote: > On Wednesday, 11 June 2014 at 06:30:26 UTC, Walter Bright wrote: >> On 6/10/2014 11:11 PM, deadalnix wrote: >>> On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright wrote: >>>> Hmm, this could have serious problems with the following: >>>> >>>> S1 s1; >>>> S2 s2; >>>> s2.c = 3; >>>> memcpy(&s2.s1, &s1, sizeof(S1)); // Oops! stomped on s2.c >>> >>> Yes, that is why they do it only in specific condition (ie when the thing use >>> C++ specific feature and not C one). >> >> I don't understand - didn't you say this was expressible as C structs? Aren't >> those supposed to be compatible with C? >> >> > > struct S1 { > int a; > private: > char b; > }; > > struct S2 : S1 { > char c; > }; > > S2 is 8 bytes. If you remove private in S1, then S2 becomes 12 bytes. S1 is not > a "C" struct anymore and do not need to follow the standard layout. Ok, I understand that, but I'd find it surprising behavior that a protection attribute affected layout. >>> and certainly not in @safe D. >> >> I'm not so sure about that, either. There are many ways of bit copying >> structs, and some of them are perfectly memory safe. >> > > It is not provable by the compiler, therefore it is not @safe. What's not provable? Why would bit copying a struct not be memory safe? >> The fundamental problem with this optimization is now a struct has two sizes - >> the unpadded and the padded size. I foresee nothing but problems, corner >> cases, and bugs inherent in trying to select which size to use for which >> purpose. I do not understand how C++ avoids these issues. > > By not spilling out for struct that do not have standard layout. In above > example, the compiler won't issue code that manipulate the padding after S1 as > it may contains something. Ok, I can see that, but forcing memberwise copy has its own efficiency problems, especially when doing things like enregistering it.