470,631 Members | 1,713 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,631 developers. It's quick & easy.

Why isn't multiple inheritance very useful?

Vla
why did the designers of c++ think it would be more useful than it turned
out to be?
Jul 22 '05 #1
30 2446
Vla wrote:
why did the designers of c++ think it would be more useful than it turned
out to be?


I guess you haven't read "Modern C++ Design"...
Jul 22 '05 #2
Why do people asked loaded rhetorical questions in the most innocent
manner possible?

Jul 22 '05 #3

"Vla" <ba***@pors.com> wrote in message
news:35*************@individual.net...
why did the designers of c++ think it would be more useful than it turned
out to be?


I don't know. Want me to ask them? I've got their cell phone numbers here
somewhere... :-)

-H
Jul 22 '05 #4
Vla wrote:
why did the designers of c++ think it would be more useful than it turned
out to be?


Why? Isn't multiple inheritance very useful?

--
WW aka Attila
:::
Business - the art of extracting money from another man's pocket without
resorting to violence. -- Max Amsterdam
Jul 22 '05 #5
Vla

"Joseph Turian" <tu****@gmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
Why do people asked loaded rhetorical questions in the most innocent
manner possible?


Whether true or not, it certainly is, or at least was, a widely held belief,
that multiple inheritance doesn't turn out to be of much practical use.
Perhaps in the couple years since I last heard that (or read it) "modern c++
design" has evolved to include widespread use of multiple inheritance. My
question would then become "why did it take so long for multiple inheritance
to catch on".

Unless you want to deny that multiple inheritance was ever considered to be
a slight disappointment regarding its practical use.
Jul 22 '05 #6
Vla wrote:
why did the designers of c++ think it would be more useful than it turned
out to be?


Multiple inheritance is very useful.
Beware the Diamond pattern.
Read the FAQ about inheritance.
Consult "Design Patterns" about multiple inheritance.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

Jul 22 '05 #7
Vla wrote:
[redacted]
Whether true or not, it certainly is, or at least was, a widely held belief,
that multiple inheritance doesn't turn out to be of much practical use.


And in years past, it was a widely held belief that the world was flat.
Your point?

Read the book "Modern C++ Design", by Andrei Alexandrescu to see what
Victor was talking about.

Jul 22 '05 #8
On Thu, 20 Jan 2005 23:00:44 +0000, Howard wrote:

"Vla" <ba***@pors.com> wrote in message
news:35*************@individual.net...
why did the designers of c++ think it would be more useful than it turned
out to be?


I don't know. Want me to ask them? I've got their cell phone numbers here
somewhere... :-)

-H


its funny how ppl just insult others or try to be funny because they dont
like the question they asked. The guy asked a question if you dont know
the answer are feel its stupid then dont reply to it.

Jul 22 '05 #9
I am not sure whether you guys are joking, or these are serious
concerns. Multiple inheritance is not possible for virtual machines
with the technology underlying Smalltalk, Java and C#. It is easy to
see who spreads the word that multiple inheritance is complicated. The
question is, who is it complicated for? The designer of the language or
the engineer?

There are many ordinary problems whose implementation becomes
excessively long, and far from the intuitive view of the problem when
one is forced to use single inheritance.

You can find a superset of C++ running on a tiny virtual machine. Visit
www.zhmicro.com

Enjoy it.

Jul 22 '05 #10
Vla wrote:
why did the designers of c++ think it would be more useful than it turned
out to be?


Why do you think the designers of c++ thought it would be more useful
than it is ?

BTW - If I was a C++ designer, and I thought back then that multiple
inheritance would be as useful as I now think it is, I'd be quite happy
with myself.

G
Jul 22 '05 #11
Vla wrote:
why did the designers of c++ think it would be more useful than it turned
out to be?


I think it -is- very useful. I'm not sure who the people are telling you
it wouldn't be useful. Probably Java enthusiasts. In fact, the lack of
multiple inheritance in Java can be an annoyance, because you have to
workaround using interfaces and delegation. It makes your code slower,
but you end doing the same thing basically.

By the way, multiple inheritance doesn't even need to be as error prone
as a lot of people claim. Look at Eiffel or Sather or Objective C, they
have pretty clever mechanisms to deal with multiple inheritance.

Regards,
Matthias
Jul 22 '05 #12
Zorro wrote:
It is easy to
see who spreads the word that multiple inheritance is complicated. The
question is, who is it complicated for? The designer of the language
or the engineer?
That question could prove more difficult to answer than one might think.
Interface-style MI as supported by Java & C# surely makes things easier
for language designers and the people who actually implement the
language. However, a nice side-effect is that easier implementations
also often perform much better. Specifically, garbage collectors and
casts are faster in the absence of full MI and that also benefits the
language users.
There are many ordinary problems whose implementation becomes
excessively long, and far from the intuitive view of the problem when
one is forced to use single inheritance.


Right. However, both the Java and the CLR/C# teams felt that performance
is more important than a releatively rarely used language feature,
which - given that you control the code of all classes you want to
inherit from - can easily be simulated with intefaces.

Regards,

--
Andreas Huber

When replying by private email, please remove the words spam and trap
from the address shown in the header.

Jul 22 '05 #13
Vla wrote:
why did the designers of c++ think it would be more useful than it turned
out to be?


I'm not entirely sure what you mean, and anyway your subject and body
ask two quite different questions.

ATMS, multiple inheritance is a relatively complex feature. As such,
some languages have decided not to include full MI, but offer such
partial solutions as interfaces and mixins. This was part of the design
of D:

http://www.digitalmars.com/d/overview.html

"Features to Drop"
"Multiple inheritance. It's a complex feature of debatable value. It's
very difficult to implement in an efficient manner, and compilers are
prone to many bugs in implementing it. Nearly all the value of MI can be
handled with single inheritance coupled with interfaces and aggregation.
What's left does not justify the weight of MI implementation."

As for why MI was included in C++, maybe it was a matter of believing
that it might come in useful one day, rather than having any particular
practical uses in mind. And eventually people found uses.

Now that some languages provide these partial solutions, there is more
scope for debate over MI's usefulness.

Stewart.

--
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
Jul 22 '05 #14
Zorro wrote:
Multiple inheritance is not possible for virtual machines
with the technology underlying Smalltalk, Java and C#.


Well, maybe in the sense that these VMs weren't desiged to support
multiple inheritance. But that's a design decision, not an inherent
limitation. This reminds me of the assertion I once saw in a Java
magazine that C++ couldn't have garbage collection because it doesn't
run in a VM. The two have nothing to do with each other. (Our compiled
Java implementation doesn't run in a VM, but it does have garbage
collection).

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 22 '05 #15
Pete Becker wrote:
<snip>
Well, maybe in the sense that these VMs weren't desiged to support
multiple inheritance. But that's a design decision, not an inherent
limitation. This reminds me of the assertion I once saw in a Java
magazine that C++ couldn't have garbage collection because it doesn't
run in a VM. The two have nothing to do with each other. (Our compiled
Java implementation doesn't run in a VM, but it does have garbage
collection).


The same applies to GC languages that were designed to be complied into
native code. D is one; can anyone think of others?

http://www.digitalmars.com/d/

Not to mention that GC engines have been written for C++. The trouble
is that, since C++ wasn't designed with GC in mind, C++ libraries don't
tend to get on well with GC engines.

Stewart.

--
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
Jul 22 '05 #16
Stewart Gordon wrote:
Pete Becker wrote:
<snip>
Well, maybe in the sense that these VMs weren't desiged to support
multiple inheritance. But that's a design decision, not an inherent
limitation. This reminds me of the assertion I once saw in a Java
magazine that C++ couldn't have garbage collection because it doesn't
run in a VM. The two have nothing to do with each other. (Our compiled
Java implementation doesn't run in a VM, but it does have garbage
collection).


The same applies to GC languages that were designed to be complied into
native code. D is one; can anyone think of others?


There are a billion, they just get less hype than D. xBase++ was one of
them, but I am sure there are many others.

--
WW aka Attila
:::
Never say 'OOPS!' Always say 'Ah, Interesting!'
Jul 22 '05 #17
[ ... ]
The same applies to GC languages that were designed to be complied into native code. D is one; can anyone think of others?


Oh, let's see: ML/SML, Algol68, Modula III, Eiffel (after "freezing"),
BASIC (GC only on strings), a multitude of LISP variants, Simula,
several SNOBOL 4 variants (e.g. Fastbol), Icon, Haskell, Sather (at
least sometimes does native compilation, though I'm not sure about
whether it was really designed with that in mind), etc., ad off-topic
naseum.

--
Later,
Jerry.

The univserse is a figment of its own imagination.

Jul 22 '05 #18
Andreas, there is a lot of truth in your statements. But think about
this.
Java does not have enumeration type. It turn out that one actually
needs it. So, in Java one turns a class into a global namespace by
declaring everything in it as static. That simulates enumeration.
However, just because one has MI available, it does not mean that one
should use it where it makes no sense. But when it is needed,
simulating it is awkward, just as simulating enumeration is.
Regards,
Z.

Jul 22 '05 #19
Yes Pete, it was a natural design decision for Smalltalk language based
on the idea used to implement its stack machine. The design here is
that a super class will be the base for everything.
So now the question for Java is this. Did they first research the
language and its suitability for expressing problems, and then they
made the VM, or, from what they could do with VM, they put a language
together?
As for garbage collection, it is not easy to just say a few things
about pointers and make much sense. However, Java garbage collection is
a consequence of yet another difficult issue. Have you noticed that all
interpreted languages, and those running on VM do not have pointers? It
is a lot easier to do garbage collection, and then make a big deal
about it.
The use of pointers is extremely difficult. But then, should we trust a
truck driver to fly a plane, or vice versa? So every engineer has
his/her favorites and experience.

Regards,
Z.

Jul 22 '05 #20
Joseph Turian wrote:
Why do people asked loaded rhetorical questions in the most innocent
manner possible?


Particularly about religious issues.[1] This looks to be a well-formed
troll (intentional or otherwise) given the responses it's generating.
[1] http://www.catb.org/~esr/jargon/html...us-issues.html
Jul 22 '05 #21
Zorro wrote:
Andreas, there is a lot of truth in your statements. But think about
this.
Java does not have enumeration type. It turn out that one actually
needs it. So, in Java one turns a class into a global namespace by
declaring everything in it as static. That simulates enumeration.
I believe it was a mistake to not give Java an enum type. In terms of
implementation, additional compiler complexity and necessary performance
trade-offs an enum is extermely cheap.
However, just because one has MI available, it does not mean that one
should use it where it makes no sense. But when it is needed,
simulating it is awkward, just as simulating enumeration is.


I agree, but as I pointed out my last message: Full MI has its price,
especially in a GCed language. I think it speaks volumes that none of
the modern GCed languages support full MI. Yes, this is sometimes
inconvenient and rarely just downright annoying, but the benefit of this
is that garbage collectors perform much better. The important part is
that GC is faster for *everyone* and *always* while full MI is a true
advantage only rarely (in a single-rooted inheritance tree). It's a
trade-off.

Regards,

--
Andreas Huber

When replying by private email, please remove the words spam and trap
from the address shown in the header.

Jul 22 '05 #22
Vla wrote:
Whether true or not, it certainly is, or at least was, a widely held belief,
that multiple inheritance doesn't turn out to be of much practical use.
Perhaps in the couple years since I last heard that (or read it) "modern c++
design" has evolved to include widespread use of multiple inheritance. My
question would then become "why did it take so long for multiple inheritance
to catch on".

Unless you want to deny that multiple inheritance was ever considered to be
a slight disappointment regarding its practical use.

Multiple inheritance is in widely use. One example of widely used
multiple inheritance is the use of interfaces.


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #23
Zorro wrote:
I am not sure whether you guys are joking, or these are serious
concerns. Multiple inheritance is not possible for virtual machines
with the technology underlying Smalltalk, Java and C#. It is easy to
see who spreads the word that multiple inheritance is complicated. The
question is, who is it complicated for? The designer of the language or
the engineer?

Java and C# support multiple inheritance from interfaces only. They do
not support complete multiple inheritance but they do support this subset.
And more precisely (as you mentioned) it is not supported by the
underlying VM. So .NET does not support complete multiple inheritance,
and it is not a C# issue. Complete multiple inheritance is not available
to C++ too, when writing .NET managed code.


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #24
Zorro wrote:
As for garbage collection, it is not easy to just say a few things
about pointers and make much sense. However, Java garbage collection is
a consequence of yet another difficult issue. Have you noticed that all
interpreted languages, and those running on VM do not have pointers? It
is a lot easier to do garbage collection, and then make a big deal
about it.
Java does have pointers, but they call them references.
The use of pointers is extremely difficult.


The use of pointers is easy. It's pointer arithmetic that can get
tricky, and makes garbage collection harder. But there's nothing
insurmountable there.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 22 '05 #25
I apologize if you found the introduction of an evolution religiously
offensive. I am actually apologizing although it may be possible to
interpret statements in different ways.
On a search I came accross this topic. I could not resist the
temptation to rectify the effects of a poison that is being spread with
negative propaganda. The question got my attention because I hear it
from every Java programmer, and when I ask them if they have ever used
multiple-inheritance, or they even know what is bad about MI, the
answer is definitely negative.
An evolution will take place, trolling or otherwise. It is only worth
your time to try to contribute. For instance, what do you find wrong
with the responses? Can you help other readers avoid getting confused?
I thought the purpose of these discussions is that someone posts a
question for clarification. Those who are interested in the same topic,
share their views. Am I wrong?

Regards,
Z.

Jul 22 '05 #26
On Sat, 22 Jan 2005 12:01:49 +0100, Andreas Huber wrote:
Zorro wrote:
Andreas, there is a lot of truth in your statements. But think about
this.
Java does not have enumeration type. It turn out that one actually
needs it. So, in Java one turns a class into a global namespace by
declaring everything in it as static. That simulates enumeration.


I believe it was a mistake to not give Java an enum type. In terms of
implementation, additional compiler complexity and necessary performance
trade-offs an enum is extermely cheap.


So did the Java community. Java now has an enum type which is a
fully-featured class, just like any other -- but with fixed, pre-created
instances.
Jul 23 '05 #27
Jerry Coffin wrote:
[ ... ]
The same applies to GC languages that were designed to be complied
into native code. D is one; can anyone think of others?


Oh, let's see: ML/SML, Algol68, Modula III, Eiffel (after "freezing"),
BASIC (GC only on strings),

<snip>

How many BASIC dialects were made to be compiled rather than
interpreted? And anyway, whether it uses GC on strings is surely
implementation dependent. Two options come to mind:
- use GC, copy on write (maybe this is one instance in which reference
counting would be the more efficient option)
- copy on assignment, deallocate when it goes out of scope (in some
primitive BASICs that don't have procedures, this would mean deallocate
never, or perhaps only when assigned the value "")

Stewart.

--
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
Jul 23 '05 #28
Stewart Gordon wrote:

[ ... ]
How many BASIC dialects were made to be compiled rather than
interpreted?
The question was not dialects, but language. The language was
originally designed to be compiled to native code, and for that matter
the first implementations DID compile to native code.
And anyway, whether it uses GC on strings is surely
implementation dependent.
It was _designed_ to use GC. You can argue that it might be possible to
implement it in other ways if you want, but then the same is true of
other things as well. There definitely HAS been at least one Lisp
interpreter that didn't use GC, but that doesn't change the original
design or intent.
Two options come to mind:
- use GC, copy on write (maybe this is one instance in which reference counting would be the more efficient option)
Reference counting isn't an alternative to reference counting --
rather, it's a technique that _supports_ reference counting.
- copy on assignment, deallocate when it goes out of scope (in some
primitive BASICs that don't have procedures, this would mean deallocate never, or perhaps only when assigned the value "")


Given the memory constraints at the time (remember, BASIC has been
around since 1964) this simply wasn't a realistic option.

The bottom line: BASIC strings were designed with GC in mind, and
essentially virtually every BASIC implementation ever has used exactly
that. Theoretically there may be other options, but none of this
changes the intent of the original design, nor the fact that the
majority of BASIC implementations _have_ used GC. It is true that there
have been quite a few
BASIC interpreters, but it's also true that it was designed to be
compiled, and many implementations have done exactly that.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jul 23 '05 #29
Jerry Coffin wrote:
Stewart Gordon wrote: <snip>
Two options come to mind:
- use GC, copy on write (maybe this is one instance in which
reference counting would be the more efficient option)


Reference counting isn't an alternative to reference counting --


Whoever suggested that it should be?

Or is that a typo for "Reference counting isn't an alternative to
garbage collection" or vice versa? Again, I didn't mean to imply that
it was. Simply that reference counting might be the optimal method
(over mark-sweep or whatever) of GC in this instance. As the copying
can be skipped when the count is 1, saving some of the reallocation
overhead during string manipulations.

<snip> The bottom line: BASIC strings were designed with GC in mind, and
essentially virtually every BASIC implementation ever has used
exactly that. Theoretically there may be other options, but none of
this changes the intent of the original design, nor the fact that the
majority of BASIC implementations _have_ used GC. It is true that
there have been quite a few BASIC interpreters, but it's also true
that it was designed to be compiled, and many implementations have
done exactly that.


I see. But now that some BASICs have dynamic arrays and even partial
OOP support, I guess GC in BASIC is taken to a new level.

Stewart.

--
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
Jul 23 '05 #30
Stewart Gordon wrote:

[ ... ]
Or is that a typo for "Reference counting isn't an alternative to
garbage collection" or vice versa?
Yes, exactly.
Again, I didn't mean to imply that
it was. Simply that reference counting might be the optimal method
(over mark-sweep or whatever) of GC in this instance. As the copying can be skipped when the count is 1, saving some of the reallocation
overhead during string manipulations.
I'd tend to agree -- the primary shortcoming of reference counting is
its inability to deal with cycles, and I'm reasonable certain BASIC
woudldn't let you create a cycle in a string to start with (modulo bugs
and such, of course).

[ ... ]
I see. But now that some BASICs have dynamic arrays and even partial OOP support, I guess GC in BASIC is taken to a new level.


Probably. I haven't looked recently to know what sort of dynamic arrays
you're talking about, but many versions have been able to resize
(redim) arrays for quite a while -- but it was done explicitly, so it
could be implemented roughly like realloc is in C.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jul 23 '05 #31

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

20 posts views Thread by km | last post: by
22 posts views Thread by Matthew Louden | last post: by
29 posts views Thread by MAHESH MANDHARE | last post: by
4 posts views Thread by Matt Kruse | last post: by
11 posts views Thread by John | last post: by
47 posts views Thread by Larry Smith | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.