StreamBase
        /         \
InputStream       OutputStream
   |    \         /       |
   |   InputOutputStream  |
   |            |         | 
FailInputStream |   FileOutputStream
         \      |      /
      FileInputOutputStream

The MFC class library has been designed so that you do not need to understand MI to use MFC. MI is not used in any of the MFC classes. We have found that MI is not required to write a class library, nor is it required for writing serious applications. To use MI or not can be a personal decision, so we leave that decision to you.

Q: Possibly a common question, but why do you only support single inheritence?
A: The scenarios for supporting multiple inheritance is rare enough that we made a fundamental decision when we first created the framework to only support single inheritance. This allows us to avoid SO many pitfalls and problems and issues that frankly, when we were shipping V1, allowed us to get the product out the door way faster than we could have otherwise. Now I know that architects in our organization continue to think about how we might do this in the future, but to be honest, it would be unbelievably hard now, probably harder than it was initially (we'd have that whole compatibility thing to worry about, and we have made fundamental CLR decisions assuming single inheritance is in place). It's one of those decisions that we had to make a LONG time ago, and it affects us from that point on.

A>Не нашёл ответа, но жутко интересно

A>Объясните пожалуйста

Одна из проблем в ООП становится особенно явной после введения как в C++, где все классы должны быть, в конце концов, наследованы от единственного базового класса. Java (как фактически и во всех ООП языках) отвечает “да” и имя этого единственного базового класса Object. Это позволяет свести иерархию к единому корню.

Все объекты в иерархии с единым корнем имеют общий интерфейс, так что они все приводятся к единому типу. Альтернатива (пришедшая из C++) в том, что вы не знаете, что все исходит из одного и того же фундаментального типа. С точки зрения обратной совместимости это лучше соответствует модели C и можно подумать, что ограничивает меньше, но когда вы хотите применить полное объектно-ориентированное программирование, вы должны построить вашу собственную иерархию, чтобы обеспечить такое же соглашение, которое применено в других языках ООП. А в любых новых библиотеках классов вы получаете, что используются некоторые другие несовместимые интерфейсы. Это требует введения (и возможности множественного наследования) работы с новыми интерфейсами в вашей разработке. Достигнута ли большая “гибкость” в C++? Если вам необходимо это — если вы имеете большие знания в C— это достаточно ценная вещь. Если вы начинаете с начала, другие альтернативы как Java могут часто быть более продуктивными.

Все объекты в иерархии с единым корнем (какую обеспечивает Java) могут гарантировать определенную функциональность. Вы знаете, что можете выполнить определенные базовые операции для каждого объекта вашей системы. Иерархия с единым корнем, наряду с созданием всех объектов в куче, сильно упрощает передачу аргументов (одна из наиболее сложных тем в C++).

Иерархия с единым корнем сильно облегчает реализацию сборщика мусора (который удобно встроен в Java). Необходимость поддержки может быть установлена в базовом классе, а сборщик мусора может посылать определенные сообщения каждому объекту в системе. Без иерархии с единым корнем и системой управления объектами через ссылки сложно реализовать сборщик мусора.

Так как информация о типе во время выполнения гарантирована для всех объектов, вы никогда не встретитесь с объектом, чей тип вы не можете определить. Это особенно важно с операциями системного уровня, такими как обработка исключений, и предоставляет большую гибкость в программировании.

class Foo : Bar1, Bar2
{
}
..
..
..

Foo foo = new Foo();
foo.GetHashCode() // невозможно определить какую именно GetHashCode необходимо вызывать

 T> class Foo : Bar1, Bar2
 T> {
          using Bar1.GetHashCode; // теперь возможно...
 T> }
 T> Foo foo = new Foo();
 T> foo.GetHashCode() // невозможно определить какую именно GetHashCode
 T> необходимо вызывать

#include <iostream>

// Типа наш любимый System.Object
struct Object
{
 virtual int GetHashCode(){return 0;};
};

struct Bar1: virtual Object{};

struct Bar2: virtual Object{};

struct Foo : Bar1, Bar2{};

int main(int argc, char* argv[])
{
 Foo * f = new Foo();
 std::cout << f->GetHashCode(); // все работает
 delete f;
}

struct Bar1: virtual Object{};
struct Bar2: virtual Object{};
struct Foo : Bar1, Bar2{};

Tom>class Foo : Bar1, Bar2
Tom>{
      using Bar1.GetHashCode; // Может, по аналогии?
Tom>}
Tom>..
Tom>..
Tom>..

Tom>Foo foo = new Foo();
Tom>foo.GetHashCode() // невозможно определить какую именно GetHashCode необходимо вызывать