Tail pad optimization, cache friendlyness and C++ interrop

deadalnix via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 11 00:22:50 PDT 2014


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.

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

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


More information about the Digitalmars-d mailing list