Thank you Steven for your explanations, I have done similar things in C and D, but I didn't understand what you meant.

>A is always put first, that way, a pointer to a B can always be used as a pointer to an A.<

Are you sure C specs say doing this leads to defined behaviour?
(Recently from a discussion with Walter I have learnt that D follows exactly C specs regarding such defined/undefined things.)


> What I would like is a common-sense approach to inheritance for structs that just does not allow virtual methods or interfaces, and which does not cast implicitly to the base (explicit cast is OK).  I think some designs would benefit greatly from this simple feature.  I think it's more tricky than I've described, but I think with some diligence it can be done.

I have desired some form of inheritance in D structs (before the creation of alias this, that so far I have not used much). I think Walter will not love this idea, but you can think more about its details, and then you can post it in the main D newsgroup.

Bye,
bearophile

On Thu, 27 May 2010 18:41:19 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Thank you Steven for your explanations, I have done similar things in C and D, but I didn't understand what you meant.
>
>> A is always put first, that way, a pointer to a B can always be used as a pointer to an A.<
>
> Are you sure C specs say doing this leads to defined behaviour?
> (Recently from a discussion with Walter I have learnt that D follows exactly C specs regarding such defined/undefined things.)

Xt and the Berkeley sockets library relies on it.  If it's not in the spec, then it's a de-facto standard.  I think the defined behavior is that the first member of a struct is positioned at the same address as the struct itself.

>
>> What I would like is a common-sense approach to inheritance for structs
>> that just does not allow virtual methods or interfaces, and which does not
>> cast implicitly to the base (explicit cast is OK).  I think some designs
>> would benefit greatly from this simple feature.  I think it's more tricky
>> than I've described, but I think with some diligence it can be done.
>
> I have desired some form of inheritance in D structs (before the creation of alias this, that so far I have not used much). I think Walter will not love this idea, but you can think more about its details, and then you can post it in the main D newsgroup.

Sadly, I think it is not much more than a wish.  I don't think Walter's mind can be changed on this.

-Steve

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message
news:op.vddvhs17eav7ka@localhost.localdomain...
| On Thu, 27 May 2010 17:04:35 -0400, Larry Luther <larry.luther@dolby.com>
| wrote:
|
| > "bearophile" <bearophileHUGS@lycos.com> wrote in message
| > news:ht4krg$17l9$1@digitalmars.com...
| > | On the base of your long experience do you like D so far?
| >
| > There are many things that I like and I strongly agree with the failings
| > of C++ mentioned in the docs.  I don't like the asymmetry between
structs
| > and classes.  I don't see why structs can't have inheritance.
|
| Because of the slicing problem.  It's basically something like this:
|
| struct A {virtual void foo();};
|
| struct B : A {virtual void foo();};
|
| void bar(A a)
| {
|   a.foo();
| }
|
| void baz()
| {
|   B b;
|   bar(b); // b is "sliced" down to an A, and bar will now call A.foo
| instead of the expected B.foo.
| }
|
| The really bad part about this is, b might have set up its private
| variables so that to call A.foo would cause an error.
|
| Same thing happens when returning by value.  The general issue is that
| inheritance and value types don't mix.  But reference types (that is,
| types that are always passed by reference) never have the slicing
| problem.  So classes in D (which are reference types) can inherit, while
| structs (which *can be* value types) cannot inherit.  I have hoped that at
| some point, structs can be auto-composed, without a vtable, but you still
| have to do this manually.  Luckily, it's not so much of a chore now that
| alias this is around.
...

I have verified the slicing problem within C++.
The problem disappears (in accordance with your statements) if "bar"
is declared such that it's argument is passed by reference.
The bottom line is that C++ overcame this sufficiently to allow
inheritance for structs.

On Wed, 02 Jun 2010 13:47:35 -0400, Larry Luther <larry.luther@dolby.com> wrote:

>
> I have verified the slicing problem within C++.
> The problem disappears (in accordance with your statements) if "bar"
> is declared such that it's argument is passed by reference.
> The bottom line is that C++ overcame this sufficiently to allow
> inheritance for structs.

C++ did not overcome it, as you just discovered, it still can happen.  What they did is put a band-aid on it, and said "always use the band-aid."  That is not a good solution.  Plus, you must always use references to truly solve the problem.

In D classes are always passed by reference, so the problem cannot occur.  Structs cannot have inheritance so the problem cannot occur.  In D, the problem cannot occur, so D has successfully overcome the problem.

BTW, from Day 1, C++ structs and classes are equivalent except for one notion -- the default protection in classes is private, the default protection in structs is public.  There is no other difference.  So it's not like they waited to add inheritance to structs until they added references to solve the slicing problem.

-Steve