в с++ разрешено множестенное наследование
в с# — нет.

объясняется тем что помогает избежать многих ошибок но что то этих ошибок я представить не могу.
но я уверен что если множестевнное наследование запретили в c# значит ошибки были действиетльно важные и избежать из было трудно.

abstract class CBase
{
protected int _i;

public abstract void DoIt();
}

class C1 : CBase
{
public virtual void DoIt()
{
_i = 1;
}
}

class C2 : CBase
{
public virtual void DoIt()
{
_i = 2;
}
}

class C3: C1, C2
{
public void Do()
{
DoIt();
Console.Write(i); // ???
}
}

Здравствуйте, Аноним, Вы писали:

А>abstract class CBase
А>{
А>protected int _i;

А>public abstract void DoIt();
А>}

А>class C1 : CBase
А>{
А>public virtual void DoIt()
А>{
А>_i = 1;
А>}
А>}

А>class C2 : CBase
А>{
А>public virtual void DoIt()
А>{
А>_i = 2;
А>}
А>}

А>class C3: C1, C2
А>{
А>public void Do()
А>{
А> DoIt();
А> Console.Write(i); // ???
А>}
А>}


1. мне кажется не i а _i
2. _i ты и не увидишь даже из С3
3. а если даже и наследовать так:

class C1 : public CBase
class C2 : public CBase

то почему бы и не обращаться по полному квалификационному имени?
типа

class C3: C1, C2
{
 public void Do()
 {
   С1::DoIt();
   Console.Write(C1::_i);
 }
}

зы: а если ты имел ввиду вызов неизвестного DoIt()

class C3: C1, C2
{
 public void Do()
 {
   DoIt();
   Console.Write(i); // ???
 }
}

такое вообще скомпилиться?
если да то плохо, но в любом случае надо указывать С1::DoIt(); или С2::DoIt();
или с таким явным указанием тоже есть какие то проблемы?

Здравствуйте, Аноним, Вы писали:

А>в с++ разрешено множестенное наследование
А>в с# — нет.

А>объясняется тем что помогает избежать многих ошибок но что то этих ошибок я представить не могу.
А>но я уверен что если множестевнное наследование запретили в c# значит ошибки были действиетльно важные и избежать из было трудно.

Я бы еще добавил, что множественное наследование — это white-box reuse, т.е. известна реализация базового класса (следовательно появляется зависимость). При множественном же наследовании интерфейсов для реализации можно использовать композицию объектов, т.н. black-box reuse (нет зависимости от реализации).
Второе с точки зрения проектирования более правильно, поскольку первое нарушает инкапсуляцию.

А>1. мне кажется не i а _i
Ну да, очепятка.
А>2. _i ты и не увидишь даже из С3
? В этом и суть.
А>то почему бы и не обращаться по полному квалификационному имени?
...
А>или с таким явным указанием тоже есть какие то проблемы?
Ну конечно, есть. Клиент, который обо всех этих сложностях не подозревал, просто вызывал c3.DoIt. Куда деваться бедному крестьянину?
A>такое вообще скомпилиться?
Код имеет такую тенденцию — меняться со временем.

Факт остается фактом, даже при наличии понятия виртуального наследования с++ имеет с этим проблемы. Они носят скорее практический, чем теоретический характер.
В системах с общим базовым предком у всех классов ситуация становится просто невыносимой. Собственно, ни одна такая система (из известных мне) ее и не вынесла.
Насколько я помню, даже mfc и managed c++ этим отличаются.

Здравствуйте, Аноним, Вы писали:

А>>1. мне кажется не i а _i
А>Ну да, очепятка.
А>>2. _i ты и не увидишь даже из С3
А>? В этом и суть.
А>>то почему бы и не обращаться по полному квалификационному имени?
А>...
А>>или с таким явным указанием тоже есть какие то проблемы?
А>Ну конечно, есть. Клиент, который обо всех этих сложностях не подозревал, просто вызывал c3.DoIt. Куда деваться бедному крестьянину?
A>>такое вообще скомпилиться?
А>Код имеет такую тенденцию — меняться со временем.

А>Факт остается фактом, даже при наличии понятия виртуального наследования с++ имеет с этим проблемы. Они носят скорее практический, чем теоретический характер.
А>В системах с общим базовым предком у всех классов ситуация становится просто невыносимой. Собственно, ни одна такая система (из известных мне) ее и не вынесла.
А>Насколько я помню, даже mfc и managed c++ этим отличаются.

короче понятно
в теории всего можно избежать а напрактике все по-другому
это как dl-hell
вроде и можно же четко делать и никаких проблем но на практике вылилось очень дажене маленькую проблему...

а вообщем я согласен что проблем после запрета множественного наследования меньше.

один предок и куча интерфесов — все же удобно

зы: но хотелось бы посмотреть на зверя типа class
MyUserControl : DataGridView, ListView

Здравствуйте, Аноним, Вы писали:

А>зы: но хотелось бы посмотреть на зверя типа class
А>MyUserControl : DataGridView, ListView

Сложно быть паровозом и велосипедом одновременно.

Ну — не совсем. Тут проблема посерьезнее.
Беда в том, что в с++ приходится быть крепким задним умом — проблема возникнет бог знает когда и бог знает у кого и в каком коде, а виртуальное наследование нужно уже сейчас. А как быть с библиотечными классами?

Единственное реальное решение — это вводить механизм явного управления веткой наследования каждого виртуального метода и (вполне вероятно, я не силен в теории) каждого member-а, причем не только у непосредственных предков, но и у всей иерархии.

Dll-hell возникает только если что-то делать не так, не соблюдать простых правил. А тут hell обеспечен в любом случае.

Так что тут уже что в лоб, что по лбу. Что вводить неимоверно сложный механизм управления в язык, что оставить его простым, а программистам предложить pattern с агрегацией — и пусть выкручиваются как хотят. Кстати, есть вспомогательный tool-ы для этого дела.

Хотя я (ей-богу) предпочел бы язык с множественным наследованием, но урезанным. Скажем, ввести помимо struct-ов еще понятие mixin-а и разрешить класам иметь только одного предка не-mixin-а и сколько угодно mixin-ов. Ну а для последних и ввести нужный набор ограничений/механизмов. А еще очень бы хотелось новенькую губозакатывательную машинку.

Здравствуйте, Andrbig, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>зы: но хотелось бы посмотреть на зверя типа class
А>>MyUserControl : DataGridView, ListView

A>Сложно быть паровозом и велосипедом одновременно.

а в с++ еще и можно

Здравствуйте, <Аноним>, Вы писали:

А>в с++ разрешено множестенное наследование
А>в с# — нет.
А>объясняется тем что помогает избежать многих ошибок но что то этих ошибок я представить не могу.
А>но я уверен что если множестевнное наследование запретили в c# значит ошибки были действиетльно важные и избежать из было трудно.

Объясняется тем, что c# компилирует в MSIL. Туда же компилируют и VB#, и другие. А в этих других _нет_ множественного наследования. А для использования C#-класса в VB#-классе они жолжны быть совместимы. Вон есть managedC++. попробуй на нём сделать множественное наследование...

Здравствуйте, DenisCh, Вы писали:

DC>Здравствуйте, <Аноним>, Вы писали:

А>>в с++ разрешено множестенное наследование
А>>в с# — нет.
А>>объясняется тем что помогает избежать многих ошибок но что то этих ошибок я представить не могу.
А>>но я уверен что если множестевнное наследование запретили в c# значит ошибки были действиетльно важные и избежать из было трудно.

DC>Объясняется тем, что c# компилирует в MSIL. Туда же компилируют и VB#, и другие. А в этих других _нет_ множественного наследования. А для использования C#-класса в VB#-классе они жолжны быть совместимы. Вон есть managedC++. попробуй на нём сделать множественное наследование...

vb# — a это кто?

По мне так не зачем, а почему. Неспособность реализовать множественного наследования при данной архитектуре выдали за преимущество. Если, что я не пытаюсь доказать, что множественно наследование крайне необходимо и без него жить нельзя.

P.S. Гради Буч:
Необходимость множественного наследования в OOP остается предметом горячих споров. По нашему опыту, множественное наследование — как парашют: как правило, он не нужен, но, когда вдруг он понадобится, будет жаль, если его не окажется под рукой.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, <Аноним>, Вы писали:

А>vb# — a это кто?

VB.NET

Здравствуйте, DenisCh, Вы писали:

DC>Здравствуйте, <Аноним>, Вы писали:

А>>vb# — a это кто?

DC>VB.NET

ну ты ж так и пешы

Здравствуйте, <Аноним>, Вы писали:


А>>>vb# — a это кто?
DC>>VB.NET
А>ну ты ж так и пешы

Это ж на 4 символа длиннее!

Здравствуйте, DenisCh, Вы писали:

DC>Здравствуйте, <Аноним>, Вы писали:


А>>>>vb# — a это кто?
DC>>>VB.NET
А>>ну ты ж так и пешы

DC>Это ж на 4 символа длиннее!

так нету такого языка как VB#

По своим функциональным возможностям языки могут как угодно отличаться друг от друга, а для обеспечения совместимости существует Common Language Specification (CLS).

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, DenisCh, Вы писали:

А>>в с++ разрешено множестенное наследование
А>>в с# — нет.
А>>объясняется тем что помогает избежать многих ошибок но что то этих ошибок я представить не могу.
А>>но я уверен что если множестевнное наследование запретили в c# значит ошибки были действиетльно важные и избежать из было трудно.

DC>Объясняется тем, что c# компилирует в MSIL. Туда же компилируют и VB#, и другие. А в этих других _нет_ множественного наследования. А для использования C#-класса в VB#-классе они жолжны быть совместимы. Вон есть managedC++. попробуй на нём сделать множественное наследование...

Это не аргумент. VB# создавался для .Net, отличия от старого VB afaik очень значительные. Т.е. в VB# нет множественного наследования из-за того, что множественного наследования нет в .Net.

Здравствуйте, Аноним, Вы писали:

А>а вообщем я согласен что проблем после запрета множественного наследования меньше.
А>один предок и куча интерфесов — все же удобно
А>зы: но хотелось бы посмотреть на зверя типа class
А>MyUserControl : DataGridView, ListView

А вот звери типа CMyControl : LWindow, LListener, LController очень даже существуют и неплохо применяются.
Кстати, использование интерфейсов — это тоже своего рода множественное наследование. Только урезанное.

Здравствуйте, shadowmaan1, Вы писали:

S>По своим функциональным возможностям языки могут как угодно отличаться друг от друга, а для обеспечения совместимости существует Common Language Specification (CLS).

Вот именно. А как раз в этом CLS и нету МН именно по вопросам совместимости.