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.
