There are a number of reasons we don't implement Multiple Implementation Inheritance directly. (As you know, we support Multiple Interface Inheritance).
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.
...................................................................................................................................
Multple inheritance is coneceptually wrong. It shouldn't be allowed in any language. Inheritance is the strongest relationship that can be expressed in OO languages. It's used to express IS-A relationship. Aggregation is used to express IS CONSTRUCTED IN TERMS OF. If you're using multiple inheritance in C++ then you're design is wrong and you probably want to use aggregation. On the other hand it's plausible to want to use multiple interfaces. For instance you might have a class wheel and a class engine. You could say that your class car inherits from wheel and from engine but that's wrong. In fact car aggregates wheel and engine because it is built in terms of those classes. If wheel is an interface and engine is an interface then car must inherit both of these interfaces since it must implement the functionaity of wheel and engine .On this basis we can see that multiple inheritance for classes should not be allowed because it promotes mis-use of the strong IS-A relationship. C# enforces the correct concepts whilst C++ allows mis-use. multiple interface inheritance is permissible and C# allows this. It's all to do with properly understanding OO concepts.Try reading Exceptional C++ by Herb Sutter to get a good discussion of the correct and incorrect uses of inheritance.
............................................................................................................................................................
As one of my friend has specified that there is pointer concept in C++ and its not possible in C#. Even the pointers can be achieved through putting the same code in UnSafe.
According to me Its not possible because inventors wanted to avoid the name collison in case if the derived class is inheriting two base classes and if the method names are the same would result in collision..
This could be one of the reason I dont admit that this is the primary reason.
but this can be achived thru Interfaces
........................................................................................................................................................
To avoid name collision. Multiple Inheritence can have many classes and methods and its quite possible that they can have save name say a save function in two different classe name can be Save() but implementation can be different . The derived class will have problem accessing the correct function.
.........................................................................................................................................................
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.
...................................................................................................................................
Multple inheritance is coneceptually wrong. It shouldn't be allowed in any language. Inheritance is the strongest relationship that can be expressed in OO languages. It's used to express IS-A relationship. Aggregation is used to express IS CONSTRUCTED IN TERMS OF. If you're using multiple inheritance in C++ then you're design is wrong and you probably want to use aggregation. On the other hand it's plausible to want to use multiple interfaces. For instance you might have a class wheel and a class engine. You could say that your class car inherits from wheel and from engine but that's wrong. In fact car aggregates wheel and engine because it is built in terms of those classes. If wheel is an interface and engine is an interface then car must inherit both of these interfaces since it must implement the functionaity of wheel and engine .On this basis we can see that multiple inheritance for classes should not be allowed because it promotes mis-use of the strong IS-A relationship. C# enforces the correct concepts whilst C++ allows mis-use. multiple interface inheritance is permissible and C# allows this. It's all to do with properly understanding OO concepts.Try reading Exceptional C++ by Herb Sutter to get a good discussion of the correct and incorrect uses of inheritance.
............................................................................................................................................................
As one of my friend has specified that there is pointer concept in C++ and its not possible in C#. Even the pointers can be achieved through putting the same code in UnSafe.
According to me Its not possible because inventors wanted to avoid the name collison in case if the derived class is inheriting two base classes and if the method names are the same would result in collision..
This could be one of the reason I dont admit that this is the primary reason.
but this can be achived thru Interfaces
........................................................................................................................................................
To avoid name collision. Multiple Inheritence can have many classes and methods and its quite possible that they can have save name say a save function in two different classe name can be Save() but implementation can be different . The derived class will have problem accessing the correct function.
.........................................................................................................................................................
Posts
0 comments:
Post a Comment