On 28 May 2017 at 13:30, Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
> On Sunday, 28 May 2017 at 09:09:39 UTC, Iain Buclaw wrote:
>>
>> However, for extern(D) classes, there's actually nothing stopping a D
>> compiler implementer from making class types more memory efficient, an
>> optimizing compiler could decide to re-arrange class fields as:
>>
>> class Something
>> {
>> long b;
>> int a;
>> char c;
>> }
>
>
> Yes, but you could do that for structs as well, after static analysis
> establishing that it no code in this specific program is making assumptions
> about layout.
>
> Or you could have an attribute that says that that field X should be at
> byte-offset N, but all other fields can move.
>
>> As a side note, when I talked about D at the GNU Hackers Meeting a number
>> of years back, when I said that structs and classes are two distinct types -
>> one being POD-only, the other being a reference that comes with the bells
>> and whistles of OOP - I actually got a small cheer. This gives me a very
>> strong impression of what C++ programmers think of their own situation
>> regarding struct vs class, and that we should not be so eager to follow
>> their design.
>
>
> Did they explain why? Many other languages provide a single construct with
> far more wide-ranging features than D/C++.
>
I said it all in one breath, so you could leave it up to
interpretation whether they applauded the fact that there is a
separation in semantics, or whether there is no multiple inheritance
in D (except via interfaces).
When asking one person over dinner later about what they felt was
wrong about struct/class in C++, I got the impression that because
there's almost no distinction between the two, class seems more like a
misfeature of C++. You could say that C++ should have stuck to one
type, instead of having two. And because in D we make a very clear
distinction, that justifies the reason to have both struct and class.
