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

   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

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

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.


> 
> 

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

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