www.digitalmars.com         C & C++   DMDScript  

D - Multiple inheritance

reply "Dave Emberton" <demberton-nospam nospam.digitalworkshop.com> writes:
Sorry if this has come up before..

This was all looking good to me until I read one thing:

"D classes support the single inheritance paradigm, extended by adding
support for interfaces. "

For me this relegates D from the level of an improved and tidied up C++ down
to the level of Java - i.e. useful for some purposes but without the real
power and flexibility of C++. I'm sure some would disagree, but why was this
feature missed out of D? I can only assume that the designer(s) of D doesn't
use multiple inheritance themselves so decided it was superfluous. As RTTI
is part of the language (I assume this means all casts are effectively
dynamic_cast's), then I can't see a good reason for this other than wanting
to use the super() keyword to call the base class rather than specifying the
base class by name.

I've also just been reading about the lack of template support, which again
is a bit sad.

Dave
Jan 17 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Dave Emberton" <demberton-nospam nospam.digitalworkshop.com> wrote in
message news:a2698l$31fo$1 digitaldaemon.com...

 For me this relegates D from the level of an improved and tidied up C++

 to the level of Java - i.e. useful for some purposes but without the real
 power and flexibility of C++. I'm sure some would disagree, but why was

And without bloat and complexity of C++, I must add... In most cases, interfaces are just enough where you'd use C++-style multiple inheritance. Some rare cases when it is really useful simply don't worth it, IMO. Remember the phrase from the D reference? "If a language can capture 90% of the power of C++ with 10% of its complexity, I argue that is a worthwhile tradeoff." I agree wholeheartedly.
 feature missed out of D? I can only assume that the designer(s) of D

 use multiple inheritance themselves so decided it was superfluous. As RTTI
 is part of the language (I assume this means all casts are effectively
 dynamic_cast's), then I can't see a good reason for this other than

Yes, all object casts are safe - they return null if type doesn't match (see cast.d - some info about internal structure of D classes can be borrowed from there).
 to use the super() keyword to call the base class rather than specifying

 base class by name.

You can do the latter as well, by the way =) "super" is simply a shorter form.
 I've also just been reading about the lack of template support, which

 is a bit sad.

Walter says templates will be in sooner or later. The compiler is still in too early stage to judge, anyhow.
Jan 17 2002
parent reply "Dave Emberton" <demberton-nospam nospam.digitalworkshop.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a26fj0$3oi$1 digitaldaemon.com...
 "Dave Emberton" <demberton-nospam nospam.digitalworkshop.com> wrote in
 message news:a2698l$31fo$1 digitaldaemon.com...

 And without bloat and complexity of C++, I must add...
 In most cases, interfaces are just enough where you'd use C++-style

 inheritance. Some rare cases when it is really useful simply don't worth
 it, IMO.

Having spent the last 5 years working on a large project that uses multiple inheritance extensively I have to disagree ;-) But in this case there was a particular reason for it, it's not always that useful I agree.
Remember the phrase from the D reference?

     "If a language can capture 90% of the power of C++ with 10% of its
     complexity, I argue that is a worthwhile tradeoff."

 I agree wholeheartedly.

Okay - but I don't think that the lack of multiple inheritance makes the language any less complex, because if you don't need it you just don't use it. The only place multiple inheritence causes major problems is when you have diamond inheritence with virtual base classes, and I'd be happy for that to be left out. Dave
Jan 17 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Dave Emberton" <demberton-nospam nospam.digitalworkshop.com> wrote in
message news:a26h9g$5f5$1 digitaldaemon.com...
 Okay - but I don't think that the lack of multiple inheritance makes the
 language any less complex, because if you don't need it you just don't use
 it. The only place multiple inheritence causes major problems is when you
 have diamond inheritence with virtual base classes, and I'd be happy for
 that to be left out.

The "is multiple inheritance useful or just a bug" discussion goes back at least 10 years to when it was first proposed to be added to C++. The arguments have surged to and fro ever since <g>.
Jan 17 2002
parent reply "Dave Emberton" <demberton-nospam nospam.digitalworkshop.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a27dpc$pee$1 digitaldaemon.com...
 The "is multiple inheritance useful or just a bug" discussion goes back at
 least 10 years to when it was first proposed to be added to C++. The
 arguments have surged to and fro ever since <g>.

If multiple inheritance truly isn't useful, then why have it at all? You've taken the Java approach by being able to inherit from one class and several interfaces, which is kind of "multiple inheritance lite". I think most people will see how being able to inherit from multiple interfaces is useful, so why does anyone think that being able to inherit from multiple implementiations (or partial implementations) of those interfaces is not also useful? And as I said, if you don't want to use multiple inheritance then the fact that the language can do it won't get in your way. It just seems completely unnecessary to me. Surely one of the ways to improve on C++ is to make it more object oriented, not less. Dave
Jan 18 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Dave Emberton wrote:

 If multiple inheritance truly isn't useful, then why have it at all? You've
 taken the Java approach by being able to inherit from one class and several
 interfaces, which is kind of "multiple inheritance lite". I think most
 people will see how being able to inherit from multiple interfaces is
 useful, so why does anyone think that being able to inherit from multiple
 implementiations (or partial implementations) of those interfaces is not
 also useful?

 And as I said, if you don't want to use multiple inheritance then the fact
 that the language can do it won't get in your way. It just seems completely
 unnecessary to me. Surely one of the ways to improve on C++ is to make it
 more object oriented, not less.

According to OOP theory, multiple inheritance is a good idea. But it's very difficult to pull off practically in a compiled language. The heart of the matter (to me) is that if we leave out multiple inheritance, the compiler will be simpler, smaller, less likely to have bugs (because it's easier to debug) and will be available sooner. From a technical sense, let me describe at the difficulties of MI. The first thing to remember is that a class is more or less just a structure with some compiler support that makes member function calls easy. Look at the following classes: class Foo { int i,j; int GetI() { return i; } int GetJ() { return j; } } class FooChild : Foo { int GetJ() { return 0; } } Note that there is one non-virtual member function and one virtual member function. The declaration above is somewhat like this C declaration: struct Foo { int i,j; struct { int (*GetJ)(struct Foo*); } vtable; } int Foo_GetI(struct Foo *this) { return this->i; }; int Foo_GetJ(struct Foo *this) { return this->j; }; struct FooChild { Foo parent_Foo; } int FooChild_GetJ(struct Foo *this) { return 0; }; When you create a "Foo" object, the compiler initializes the "vtable.GetJ" variable to point to "Foo_GetJ". When you create a "FooChild" object, it initializes "parent_Foo.vtable.GetJ" to point to "FooChild_GetJ". The beauty of this setup is that the parent Foo object is right at the beginning of the FooChild; thus any pointer to FooChild can be cast to a pointer to Foo without ever modifying the pointer. And since the Foo object is included whole within the FooChild, then the Foo REALLY IS there...with no special code needed, no changes required in Foo. Now consider what happens when you add a class Bar and derive Baz from Foo and Bar: class Bar { int i; int GetI() { return i*3; }; } class Baz : Foo, Bar { } Now, how do you implement this in C???? This is the closest I can come, but it's really ugly: struct Bar { int i; } int GetI(struct Bar *this) { return this->i*3; } struct Baz { Foo parent_Foo; Bar parent_Bar; } Now what does the compiler do when you try to call Baz::GetI()??? Or access Baz::i??? The answers are ambiguous unless you define complex rules for the language. Also, you can't cast a pointer to Baz to a pointer to Bar without modifying the pointer variable. Things get even worse when you have "diamond inheritance," where the same base class is included twice through two different children: class Fred : Foo {}; class Wilma : Foo {}; class Pebbles : Fred, Wilma {}; If you include two copies of Foo (the one that's part of Fred and the one that's part of Wilma), then you can't say that "Pebbles ISA Foo"...you say that "Pebbles INCLUDESA Foo (two of them)." But if you include only one copy of Foo, then you have screwed up the code in either Fred or Wilma. This is where C++ ends up having virtual classes and such. ugh. The beauty of the Java/D alternative is that you avoid all these complexities. Interfaces can be modeled as structures that are just lists of virtual function pointers. class Barney { int i; int GetI() { return i; } } class Betty { int j; int GetJ(); } interface BettyInt { int GetJ(); } class Bambam : Barney,BettyInt { // inherits i and GetI from Barney Betty betty; int GetJ() { return betty->GetJ(); } } Now this has a very workable implementation: struct Barney { int i; } int Barney_GetI(struct Barney *this) { return this->i; } struct Betty { int j; } int Betty_GetJ(struct Betty *this) { return this->j; } struct BettyInt { int (*GetJ)(void*); } struct Bambam { Barney parent_Barney; Betty betty; } int Bambam_GetJ(struct Bambam *this) { return Betty_GetJ(this->betty); } When you cast a pointer to Bambam into a pointer to Betty, it just takes the GetJ that Bambam has and stores that in the BettyInt. The beauty here is that the one object you inherit doesn't have ANY implementation changes, and the interface is defined from the very beginning to be nothing but a huge vtable. This vastly simplifies the compiler. Now, I'm not arguing that multiple inheritance is structurally bad...but it is difficult to implement for relatively little gain. -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jan 18 2002
next sibling parent reply "J. Daniel Smith" <j_daniel_smith deja.com> writes:
Yes.  As I understand Walter's reasoning, he's omitting "full" multiple
inheritence for practical reasons, not philisophical ones.  It's not about
whether or not multiple inheritence is useful, it's about developing a
language in which you stand a better chance of writing bug-free code and
having a compiler which correctly implements that language.

As can be seen from the C++ specification, getting all the details for
complete multiple inheritence specified is hard enough; but then you've got
to write a compiler which correctly implements all of that.  Everything is
much simplier with just multiple interface inheritence and combined with
aggregation/delegation you can usually get the job done.

Why add a feature that is really only absolutely required 10% of the time
and then is very difficult to get right?  If you really must have full
multiple inheritence, then C++ is the right tool to use.

   Dan

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C484184.758215B deming-os.org...
 Dave Emberton wrote:

 If multiple inheritance truly isn't useful, then why have it at all?


 taken the Java approach by being able to inherit from one class and


 interfaces, which is kind of "multiple inheritance lite". I think most
 people will see how being able to inherit from multiple interfaces is
 useful, so why does anyone think that being able to inherit from


 implementiations (or partial implementations) of those interfaces is not
 also useful?

 And as I said, if you don't want to use multiple inheritance then the


 that the language can do it won't get in your way. It just seems


 unnecessary to me. Surely one of the ways to improve on C++ is to make


 more object oriented, not less.

According to OOP theory, multiple inheritance is a good idea. But it's

 difficult to pull off practically in a compiled language.  The heart of

 matter (to me) is that if we leave out multiple inheritance, the compiler

 be simpler, smaller, less likely to have bugs (because it's easier to

 will be available sooner.



 From a technical sense, let me describe at the difficulties of MI.

 The first thing to remember is that a class is more or less just a

 with some compiler support that makes member function calls easy.  Look at

 following classes:

 class Foo {
     int i,j;
     int GetI() { return i; }
     int GetJ() { return j; }
 }
 class FooChild : Foo {
     int GetJ() { return 0; }
 }

 Note that there is one non-virtual member function and one virtual member
 function.  The declaration above is somewhat like this C declaration:

 struct Foo {
     int i,j;
     struct {
        int (*GetJ)(struct Foo*);
     } vtable;
 }
 int Foo_GetI(struct Foo *this) { return this->i; };
 int Foo_GetJ(struct Foo *this) { return this->j; };
 struct FooChild {
     Foo parent_Foo;
 }
 int FooChild_GetJ(struct Foo *this) { return 0; };

 When you create a "Foo" object, the compiler initializes the "vtable.GetJ"
 variable to point to "Foo_GetJ".  When you create a "FooChild" object, it
 initializes "parent_Foo.vtable.GetJ" to point to "FooChild_GetJ".

 The beauty of this setup is that the parent Foo object is right at the

 of the FooChild; thus any pointer to FooChild can be cast to a pointer to

 without ever modifying the pointer.  And since the Foo object is included

 within the FooChild, then the Foo REALLY IS there...with no special code

 no changes required in Foo.  Now consider what happens when you add a

 and derive Baz from Foo and Bar:

 class Bar {
     int i;
     int GetI() { return i*3; };
 }
 class Baz : Foo, Bar {
 }

 Now, how do you implement this in C????  This is the closest I can come,

 it's really ugly:

 struct Bar {
     int i;
 }
 int GetI(struct Bar *this) { return this->i*3; }
 struct Baz {
     Foo parent_Foo;
     Bar parent_Bar;
 }

 Now what does the compiler do when you try to call Baz::GetI()???  Or

 Baz::i???  The answers are ambiguous unless you define complex rules for

 language.

 Also, you can't cast a pointer to Baz to a pointer to Bar without

 pointer variable.  Things get even worse when you have "diamond

 where the same base class is included twice through two different

 class Fred : Foo {};
 class Wilma : Foo {};
 class Pebbles : Fred, Wilma {};

 If you include two copies of Foo (the one that's part of Fred and the one

 part of Wilma), then you can't say that "Pebbles ISA Foo"...you say that
 "Pebbles INCLUDESA Foo (two of them)."  But if you include only one copy

 then you have screwed up the code in either Fred or Wilma.  This is where

 ends up having virtual classes and such.  ugh.



 The beauty of the Java/D alternative is that you avoid all these

 Interfaces can be modeled as structures that are just lists of virtual

 pointers.

 class Barney {
     int i;
     int GetI() { return i; }
 }
 class Betty {
     int j;
     int GetJ();
 }
 interface BettyInt {
     int GetJ();
 }
 class Bambam : Barney,BettyInt {
     // inherits i and GetI from Barney
     Betty betty;
     int GetJ() { return betty->GetJ(); }
 }

 Now this has a very workable implementation:

 struct Barney {
     int i;
 }
 int Barney_GetI(struct Barney *this) { return this->i; }
 struct Betty {
     int j;
 }
 int Betty_GetJ(struct Betty *this) { return this->j; }
 struct BettyInt {
     int (*GetJ)(void*);
 }
 struct Bambam {
     Barney parent_Barney;
     Betty betty;
 }
 int Bambam_GetJ(struct Bambam *this) { return Betty_GetJ(this->betty); }

 When you cast a pointer to Bambam into a pointer to Betty, it just takes

 GetJ that Bambam has and stores that in the BettyInt.  The beauty here is

 the one object you inherit doesn't have ANY implementation changes, and

 interface is defined from the very beginning to be nothing but a huge

 This vastly simplifies the compiler.



 Now, I'm not arguing that multiple inheritance is structurally bad...but

 difficult to implement for relatively little gain.

 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

Jan 18 2002
parent reply "Walter" <walter digitalmars.com> writes:
"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a29hl2$ka6$1 digitaldaemon.com...
 Yes.  As I understand Walter's reasoning, he's omitting "full" multiple
 inheritence for practical reasons, not philisophical ones.  It's not about
 whether or not multiple inheritence is useful, it's about developing a
 language in which you stand a better chance of writing bug-free code and
 having a compiler which correctly implements that language.

 As can be seen from the C++ specification, getting all the details for
 complete multiple inheritence specified is hard enough; but then you've

 to write a compiler which correctly implements all of that.  Everything is
 much simplier with just multiple interface inheritence and combined with
 aggregation/delegation you can usually get the job done.

 Why add a feature that is really only absolutely required 10% of the time
 and then is very difficult to get right?  If you really must have full
 multiple inheritence, then C++ is the right tool to use.

That's essentially correct. MI is a major implementation effort, but adds only minor incremental functionality to the language. MI has been around for 10 years in C++, and 10 years of experience has not made a compelling case that it's really necessary. Single inheritance handles 90% of the cases, adding interfaces handles 90% of the rest. That leaves 1% <g>. Yes, I do understand that some folks really do like MI and require it for their own style of programming.
Jan 18 2002
parent "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a2a0f1$2q5j$1 digitaldaemon.com...
 "J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
 news:a29hl2$ka6$1 digitaldaemon.com...
 Yes.  As I understand Walter's reasoning, he's omitting "full" multiple
 inheritence for practical reasons, not philisophical ones.  It's not


 whether or not multiple inheritence is useful, it's about developing a
 language in which you stand a better chance of writing bug-free code and
 having a compiler which correctly implements that language.

 As can be seen from the C++ specification, getting all the details for
 complete multiple inheritence specified is hard enough; but then you've

 to write a compiler which correctly implements all of that.  Everything


 much simplier with just multiple interface inheritence and combined with
 aggregation/delegation you can usually get the job done.

 Why add a feature that is really only absolutely required 10% of the


 and then is very difficult to get right?  If you really must have full
 multiple inheritence, then C++ is the right tool to use.

That's essentially correct. MI is a major implementation effort, but adds only minor incremental functionality to the language. MI has been around

 10 years in C++, and 10 years of experience has not made a compelling case
 that it's really necessary. Single inheritance handles 90% of the cases,
 adding interfaces handles 90% of the rest. That leaves 1% <g>.

 Yes, I do understand that some folks really do like MI and require it for
 their own style of programming.

The only thing I've really used MI for is mixins. And there are better ways to do them. For example: --- interface NamedObject { void name(int newname); int name(); } mixin MyMixin: NamedObject { char[] m_Name; void name(int newname) { m_Name = newname; } int name() { return m_Name; } } class MyClass { MyMixin; } --- Which the compiler re-arranges (macro-style) into: --- class MyClass: NamedObject { char[] m_Name; void name(int newname) { m_Name = newname; } int name() { return m_Name; } } --- That would be tremendously useful. It's very similar to the concept of "modules" in Ruby, only done at compile-time. Salutaciones, JCAB
Jan 18 2002
prev sibling parent reply "Dave Emberton" <demberton-nospam nospam.digitalworkshop.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C484184.758215B deming-os.org...
 According to OOP theory, multiple inheritance is a good idea.  But it's

 difficult to pull off practically in a compiled language.  The heart of

 matter (to me) is that if we leave out multiple inheritance, the compiler

 be simpler, smaller, less likely to have bugs (because it's easier to

 will be available sooner.

Okay - that's what we call engineering, and there's nothing wrong with that. But it seems a shame to limit a language because it would require more effort to write the compiler. The problems you mention have already been solved by C++ compilers, so it's not exactly impossible. No doubt the compiler would also be simpler if we left out contracts and unit tests and other features of D ;-) <snip>
 The beauty of this setup is that the parent Foo object is right at the

 of the FooChild; thus any pointer to FooChild can be cast to a pointer to

 without ever modifying the pointer.  And since the Foo object is included

 within the FooChild, then the Foo REALLY IS there...with no special code

 no changes required in Foo.  Now consider what happens when you add a

 and derive Baz from Foo and Bar:

 class Bar {
     int i;
     int GetI() { return i*3; };
 }
 class Baz : Foo, Bar {
 }

 Now, how do you implement this in C????  This is the closest I can come,

 it's really ugly:

 struct Bar {
     int i;
 }
 int GetI(struct Bar *this) { return this->i*3; }
 struct Baz {
     Foo parent_Foo;
     Bar parent_Bar;
 }

 Now what does the compiler do when you try to call Baz::GetI()???  Or

 Baz::i???  The answers are ambiguous unless you define complex rules for

 language.

If you mean that both Foo and Bar have GetI() then the same as C++ - causes a compiler error. I don't see how anyone would ever want it to try and work it out. If you mean that Foo doesn't have a GetI, then I guess what the compiler needs to do is something like: Bar* pBar=(Bar*)((char*)pBaz)+sizeof(Foo) Bar_GetI(pBar)
 Also, you can't cast a pointer to Baz to a pointer to Bar without

 pointer variable.

True, but as all casts are dynamic_casts in D anyway, then a cast is never quite as simple as just using the same pointer value. Whatever mechanism makes that work must be able to make the multiple inheritance case work too.
 Things get even worse when you have "diamond inheritance,"
 where the same base class is included twice through two different

As I said, I'd be happy for the diamond inheritance to be left out as it really is a bad idea.
 Now, I'm not arguing that multiple inheritance is structurally bad...but

 difficult to implement for relatively little gain.

True - but is the goal here to create a better language, or is the goal here to create a simpler compiler? From my point of view it's a shame that it's been left out, but I accept that others may have a completely different opinion. Dave
 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

Jan 18 2002
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Dave Emberton wrote:

 Okay - that's what we call engineering, and there's nothing wrong with that.
 But it seems a shame to limit a language because it would require more
 effort to write the compiler. The problems you mention have already been
 solved by C++ compilers, so it's not exactly impossible. No doubt the
 compiler would also be simpler if we left out contracts and unit tests and
 other features of D ;-)

But that's exactly the point - none (or very few) of the compilers ever got it all right! Rather than have a good standard, C++ is a mixmash of partially incompatible compilers. In truth, to get portable, reliable code, you pretty much have to dump most of the cooler features.
 If you mean that both Foo and Bar have GetI() then the same as C++ - causes
 a compiler error. I don't see how anyone would ever want it to try and work
 it out.

My memory is that actually it *is* possible. If both GetI's are declared as virtual functions, then it is legal. Or do you only have to declare one of them virtual? If so, which one? The point is, very few people know what the standard actually is enough to be able to use it.
 As I said, I'd be happy for the diamond inheritance to be left out as it
 really is a bad idea.

Since *all* classes in D are derived from Object, then every instance of multiple inheritance has to deal with diamon inheritance. :(
 Now, I'm not arguing that multiple inheritance is structurally bad...but

 difficult to implement for relatively little gain.

True - but is the goal here to create a better language, or is the goal here to create a simpler compiler? From my point of view it's a shame that it's been left out, but I accept that others may have a completely different opinion.

I'm just not convinced that MI gives you a better language. But I am convinced that having partially-conforming, partially incompatible compilers gives you a worse language. So it seems that MI and stuff like that would be risking almost certain downsides against very small upsides. Now, OTOH, I'm not against defining a separate standard of some sort that takes a language much like D (but uses MI) and translates it down to D. That might be workable, and could almost certainly be written in a portable script format like PERL or something. Maybe we can call it D++ :) -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jan 18 2002
prev sibling parent reply la7y6nvo shamko.com writes:
"Dave Emberton" <demberton-nospam nospam.digitalworkshop.com> writes:

 If multiple inheritance truly isn't useful, then why have it at all? You've
 taken the Java approach by being able to inherit from one class and several
 interfaces, which is kind of "multiple inheritance lite". I think most
 people will see how being able to inherit from multiple interfaces is
 useful, so why does anyone think that being able to inherit from multiple
 implementiations (or partial implementations) of those interfaces is not
 also useful?

I think there is general agreement that multiple inheritance is (which is to say, can be) useful. The question is, does multiple inheritance add enough utility to make it worth the cost of extra complexity in the language? It's hard to make a compelling case for multiple inheritance; perhaps one will be made, but I'm not aware of any example having been put forth. And I know of no study that's been done that tries to measure the cost of having multiple inheritance in a language.
 And as I said, if you don't want to use multiple inheritance then 
 the fact that the language can do it won't get in your way. 

This idea - that one can ignore language features one doesn't use - is an old one, going back at least to the 1960's, but unfortunately it isn't right. The problem is, if multiple inheritance is there, someone (in fact lots of someones) will use it. Unless you're in the position of not working with other programmers, not working on code that other people write, not using any third party software, and not using any standard libraries, you almost certainly *are* going to encounter code that uses multiple inheritance, and then you'll no longer be able to ignore its presence. So I think the idea that language features can be used by people who want them and ignored by people who don't just isn't convincing.
Jan 24 2002
parent reply Russell Borogove <kaleja estarcion.com> writes:
la7y6nvo shamko.com wrote:

 "Dave Emberton" <demberton-nospam nospam.digitalworkshop.com> writes:
And as I said, if you don't want to use multiple inheritance then 
the fact that the language can do it won't get in your way. 

This idea - that one can ignore language features one doesn't use - is an old one, going back at least to the 1960's, but unfortunately it isn't right. The problem is, if multiple inheritance is there, someone (in fact lots of someones) will use it. Unless you're in the position of not working with other programmers, not working on code that other people write, not using any third party software, and not using any standard libraries, you almost certainly *are* going to encounter code that uses multiple inheritance, and then you'll no longer be able to ignore its presence. So I think the idea that language features can be used by people who want them and ignored by people who don't just isn't convincing.

That seems like a bogus argument. If a library designer feels that multiple inheritance is important, that library designer is going to work in a language that supports it. If you and your coworkers can't agree on an acceptable language subset, you have worse problems than having to learn the perils of multiple inheritance.[1] In the particular case of MI, it seems pretty easy to ignore it even if some library class you're using uses it. The library can do its little MI dance, you can singly inherit from those library classes. If the library doesn't work right it's someone else's problem to understand and fix. To say otherwise is to make a case against using any middleware or third-party code in general, which is a separate discussion entirely. -Russell B [1] In 1994, I had to rewrite a nice chunk of code because my project lead wasn't comfortable with C++, and believed, or claimed to believe, that merely using classes -- without any virtual functions -- had unacceptable performance overhead. The team agreed to avoid C++, my code was rewritten, and I eventually quit.
 
 

Jan 24 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C50E255.6020301 estarcion.com...
 [1] In 1994, I had to rewrite a nice chunk of code because my
 project lead wasn't comfortable with C++, and believed, or
 claimed to believe, that merely using classes -- without any
 virtual functions -- had unacceptable performance overhead.
 The team agreed to avoid C++, my code was rewritten, and I
 eventually quit.

The solution there is easy - just run your C++ code through Cfront! Voila! It's now in C! You've all seen my complaints about C++, but performance of the resulting code isn't one of them. I've been careful in the design of D to not define behavior that mandates inefficient code generation. I still write most code on a 200 Mhz Pentium. Why not upgrade to a 1.7Ghz machine? Because it keeps my attention focussed on writing fast executing code. The only time I really miss a faster machine is when running the test suites, which take hours.
Jan 24 2002
prev sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C50E255.6020301 estarcion.com...
 la7y6nvo shamko.com wrote:

 "Dave Emberton" <demberton-nospam nospam.digitalworkshop.com> writes:
And as I said, if you don't want to use multiple inheritance then
the fact that the language can do it won't get in your way.

This idea - that one can ignore language features one doesn't use - is an old one, going back at least to the 1960's, but unfortunately it isn't right. The problem is, if multiple inheritance is there, someone (in fact lots of someones) will use it. Unless you're in the position of not working with other programmers, not working on code that other people write, not using any third party software, and not using any standard libraries, you almost certainly *are* going to encounter code that uses multiple inheritance, and then you'll no longer be able to ignore its presence. So I think the idea that language features can be used by people who want them and ignored by people who don't just isn't convincing.

That seems like a bogus argument. If a library designer feels that multiple inheritance is important, that library designer is going to work in a language that supports it. If you and your coworkers can't agree on an acceptable language subset, you have worse problems than having to learn the perils of multiple inheritance.[1]

exactly why the argument for implementing X because language features that can be ignored is flawed, a sound argument for not implementing X.
 In the particular case of MI, it seems pretty easy to ignore
 it even if some library class you're using uses it. The library
 can do its little MI dance, you can singly inherit from those
 library classes. If the library doesn't work right it's someone
 else's problem to understand and fix. To say otherwise is to
 make a case against using any middleware or third-party code in
 general, which is a separate discussion entirely.

then problem with MI in C++ is you get two types of inheritance Single Inheritance of one of the classes and containment of the others class B {}; class D :public B {}; you can pass D as a B and then get it back to a D but class A {}; class B {}; class D :public A,B {}; you can pass D as A or B, but only the A can be cast back to D, in C++ MI is realy just SI with cheap syntax for containment and automatically generated overloaded cast/pointer operations. C++ has a real headache even with virtual inheritance because the this pointer can not change if it did you would lose access to parts of you object. so you have to fully populate your Vtable. virtual inheritance, is saying lets add a member to my class that pointer to the location of my superclass does not solve the over all problem that casting can change the reference/pointer. Java has interfaces, to give light weight MI, it only allows virtual functions becuase of the way it works, it could have been made to work for member too. you still have to look to find out where in your object you "interface" is some method of allowing disimilar object to have an identical interface is required but full blown MI has too many nasties under the surface. not only is it a headache for the compiler writer is can be IMHO more work for the designer if you have to work with libraries that use it, than working out a design that does not require it. Mike.
Jan 25 2002