Compartilhar via

What about Templates and Multiple Inheritance

  • Artigo

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