Tail pad optimization, cache friendlyness and C++ interrop

[Walter Bright via Digitalmars-d]

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?


> This kind of thing is valid in C, but isn't
> supposed to be in C++,

I'm not so sure about that.

> 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.

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.