Tail pad optimization, cache friendlyness and C++ interrop

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 11 02:35:03 PDT 2014


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.


More information about the Digitalmars-d mailing list