What about Templates and Multiple Inheritance


A reader writes the following from the initial posting on this blog:


re: The Revised C++ Language Design Supporting .NET — Part 1


“Probably the most conspicuous and eyebrow-lifting change between the original and revised design of the dynamic programming support within C++ is the change in the declaration of a .NET reference type.”


I thought that the most conspicious and eyebrow lifting change was the absense of multiple inheritance and decent templates.


Of course, on the surface level, the reader has simply misunderstood what I wrote in order to vent his frustration. I spoke of the most conspicuous change between the original and revised design of C++/CLI. Since neither multiple inheritance nor support of managed templates were provided within the original language design, their continued absence in the revised language could not be conspicuous – except in the paradoxical sense of `your silence is deafening.’


 


I made this statement in order to point out the philosophical shift in the design of the C++/CLI language – that is, viewing the language as an additional paradigm to be supported by the language – in this sense similar to OO and generic programming (templates). This is the key to understanding the wholesale revision of the language.


 


Another significant part of making the language first class is to provide support not just for managed templates, but to support the CLR generic features as well. Not only can one declare a managed type as a template, or as a generic, but we will also provide an STL.NET library. I did not mention this previously because my blog is limited to speaking to the mapping of the original language to the C++/CLI revision. Of course, new features have no mapping.


 


The second issue, which is the support of multiple inheritance, is problematic for a number of reasons. The first, of course, is that the CLR, like Java and Smalltalk, does not support it directly. Thus, any implementation will need to internally flatten it. The question then is, has a need for it been demonstrated to warrant the expense of personnel? Currently, the answer is no.


 


There are some significant implementation and performance problems with multiple inheritance – particularly virtual base classes which contain data members. Interfaces strike me as a potentially superior design; however, I don’t have actual experience with their use. I’d like to see people gain some experience with interfaces before they claim a superiority with MI.


 


That said, there is a model of MI that we are looking at, which supports combining native and managed classes in a very interesting way. But that is in the future, and outside the boundaries of this blog. Look to the blogs of Herb Sutter and Brandon Bray for more information as time passes.


Comments (4)

  1. Frans Bouma says:

    Ah, you quoted me.

    "There are some significant implementation and performance problems with multiple inheritance – particularly virtual base classes which contain data members."

    That’s up to the user to decide to opt for this ‘performance hit’ (which is not as significant as you make it). There are also serious performance issues related to datasets or to O/R mapping. You _don’t have to_ use MI to write software, however in a SI world, things get complicated in several situations. I wrote a plea for MI in .NET here:

    http://weblogs.asp.net/fbouma/archive/2004/01/04/47476.aspx

    Besides that, C++ as a standard supports MI. You don’t support MI on .NET’s version of C++. Therefore C++ is severily crippled. You can give 10,000 excuses for that decision, that’s not the point. The point is: it’s not C++ anymore because you removed a CORNERSTONE of C++ from the language: if you want to use that feature, you have to go unmanaged. Now, isn’t the future going towards a managed world? So I don’t have a choice anymore?

    "Interfaces strike me as a potentially superior design; however, I don’t have actual experience with their use. I’d like to see people gain some experience with interfaces before they claim a superiority with MI."

    You don’t understand Interfaces clearly. You have two types of MI: multiple type inheritance and multiple implementation inheritance. .NET only supports the former, by offering the feature of multiple inheritance via interfaces. (Interfaces do support MI in .NET). This however is a ‘hack’, because although you have multiple type inheritance, you still can’t inherit a given implementation of the interface from a given base class: you have to RE-implement the interface, due to the lack of multiple implementation inheritance.

    I’ve described in my blog about MI an abstract example and you can apply that abstract example to a lot of classes in .NET’s API.

    It’s a real shame that a ‘common’ language runtime isn’t offering a platform for common features seen in a lot of languages like MI. The excuses I’ve seen for the absense of MI are , sorry, not that insightful: From ‘it’s a performance hit’ (so? what if I want to opt for simplicity in implementation over a couple of cycles?) to ‘it’s implemented in a lot of ways in various languages, which one to pick?’ (generics are also implemented in a lot of ways, still, MS has picked one and implemented it. How come generics are suddenly required, but MI is not? What if Sun didn’t include generics in the JVM, would .NET have generics by now? What if Sun had included MI in Java, would the CLR have MI by now? I think so.)

    And this scentence is really frustrating:

    "The question then is, has a need for it been demonstrated to warrant the expense of personnel? Currently, the answer is no."

    With over 50,000 employees, 40billion $ on the bank and the title ‘biggest software firm in the world’ firmly in the bag, Microsoft can’t produce MI features inside the CLR, while a small company like Eiffel Soft can (although via helper classes, but it’s a way).

    Tell, what has to happen to the earth as we know it till Microsoft says: "ok, it’s time to implement MI into .NET" ? Don’t you all understand how frustrating this is for people who do have to fight with SI limitations on a daily basis? (YES, SI has limitations which are not helped by several .NET class implementations)

    Thanks for your time.