471,570 Members | 973 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,570 software developers and data experts.

Why Doesn't c# support Multiple Inheritance ?

There are a number of reasons we don't implement Multiple Implementation
Inheritance directly. (As you know, we support Multiple Interface

However, I should point out that it's possible for compilers to create MI
for their types inside the CLR. There are a few rough edges if you go down
this path: the result is unverifiable, there is no interop with other
languages via the CLS, and in V1 and V1.1 you may run into deadlocks with the
OS loader lock. (We're fixing that last problem, but the first two problems
remain). The technique is to generate some VTables in RVA-based static
fields. In order to deposit the addresses of managed methods (which probably
haven't been JITted yet), you use the VTFixup construct. This construct is a
table of triplets. The triplets consist of a token to a managed method, an
address in your image that should be fixed up (in this case, a slot of the
VTable you are creating in the RVA-based static), and some flags. The
possible flags are described in corhdr.h and they allow you to specify 32-
vs. 64-bit pointer sizes, control over virtual behavior, and whether some
reverse-PInvoke behavior should be applied in the form of a thunk that
eventually dispatches to the managed method. If we are performing an
unmanaged->managed transition, you also have some control over which
AppDomain should be selected for us to dispatch the call. However, one of
these options (COR_VTABLE_FROM_UNMANAGED_RETAIN_APPDOMAIN) doesn't exist in
V1. We added it in V1.1.

There are several reasons we haven't provided a baked-in, verifiable,
CLS-compliant version of multiple implementation inheritance:

1. Different languages actually have different expectations for how MI
works. For example, how conflicts are resolved and whether duplicate bases
are merged or redundant. Before we can implement MI in the CLR, we have to do
a survey of all the languages, figure out the common concepts, and decide how
to express them in a language-neutral manner. We would also have to decide
whether MI belongs in the CLS and what this would mean for languages that
don't want this concept (presumably VB.NET, for example). Of course, that's
the business we are in as a common language runtime, but we haven't got
around to doing it for MI yet.

2. The number of places where MI is truly appropriate is actually quite
small. In many cases, multiple interface inheritance can get the job done
instead. In other cases, you may be able to use encapsulation and delegation.
If we were to add a slightly different construct, like mixins, would that
actually be more powerful?

3. Multiple implementation inheritance injects a lot of complexity into the
implementation. This complexity impacts casting, layout, dispatch, field
access, serialization, identity comparisons, verifiability, reflection,
generics, and probably lots of other places.

It's not at all clear that this feature would pay for itself. It's something
we are often asked about. It's something we haven't done due diligence on.
But my gut tells me that, after we've done a deep examination, we'll still
decide to leave the feature unimplemented.
please post your doubts and help me to explore ny knowledge.
Feb 15 '06 #1
1 2858
vinoraja <vi******@discussions.microsoft.com> wrote:


Note that this post was taken verbatim from a post made by Chris
Brumme. It's available in the C# FAQ at


and was also at

It's always good to include attributions rather than passing off an
answer as your own...

Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 15 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Graham Banks | last post: by
5 posts views Thread by Morgan Cheng | last post: by
20 posts views Thread by km | last post: by
22 posts views Thread by Matthew Louden | last post: by
8 posts views Thread by mmu2643 | last post: by
15 posts views Thread by iKiLL | last post: by
7 posts views Thread by Adam Nielsen | last post: by
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by lumer26 | last post: by
reply views Thread by Vinnie | last post: by
reply views Thread by lumer26 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.