Чем чревато использование множественного наследования?

юзай композицию, вместо наследования

Холиваром

В RTTI придется думать, наскочил ты на «олмаз» или еще нет :) Ни то, ни другое официально доброхотами от погромирования не поощряется - срачегонно почти как goto :) Но «миксину» любят, а «политеги» с Александреской... мммм... Сплошные искушения.

Ишшо френды бывают.

Можно ли както реорганизовать дерево классов

Можно, если знать, зачем тебе нужно множественное наследование вообще.

«Не навреди!» (с) :)

при использовании базовых классов с непересекающимися контрактиами - попоболью диванных аналитиков лора.

ну а так вообще можно попортить семантику производного класса и получить кота с кустом вместо лапы и шлангом вместо хвоста (но мы же не о быдлокодерах говорим?)

при использовании базовых классов с непересекающимися контрактиами

думай о будущем, контракты они начнут пересекаться завтра, да

а разработка набыдлогадил и забыл - она вообще другой философии требует

Легко

class base {};

class der1 {};
class der2 {};

class A: der1 {};
class B: der2 {};

class C: base, der1, der2{};

В RTTI придется думать

не нужно же ну

goto тоже :) Мало ли кому чего не нужно. Далеко не всегда код с которым имеешь дело пишется тобой и так как ты хочешь :)

Что плохого во множественном наследовании? Оно естественно для ООП. Читайте Б.Мейера(да и Буча тоже)...

думай о будущем

да я вообще стараюсь его не использовать, кроме как в совсем простецких случаях типа:

class Entity: public IRotatable, public IMovable {};

Классика по ООП без привязки к языкам только два - Буч и Мейерс. Знаешь других? В книгах по явашарпам просто выбора нет - множественное наследование там запрещено ради обезъянок.

это абсолютно не значит, что при внесении своих изменений надо писать говно, как авторы кода.

там есть множественное наследование поведения на интерфейсах. или уже выпилили?

Ага-ага. Враппер на враппере врапером враппер врапит. Есть любители этого дела. Тоже знаком.

IШтобл*? подозрительный коденг конвеншын :)

Да все хорошо... Как с любым молотком или бензопилой :) Многим искренне не нравится, что они могут что-то разбить и руки порезать («А вдруг?!» - про выстрелы в ногу и Деда Мороза я с ними не заговариваю :))

IDniwe только для классов с pure virtual методами :)

Я понял :)

смотря как ты его используешь

и лучше не скрещевать его при наследовании от фреймворков, а то я как-то уже сделал:

class MFCGrapyLayout: public CWnd, public GraphLayout { }

class MFCGrapyLayout: public GraphLayout, public CWnd { }

class C: der1, der2{};

Вот так лучше действительно не делать, имея общую базу для der1 и der2. Это если коротко. Если нужны подробности - пиши, расскажу.

Вопрос в том, зачем класс С наследует der1 и der2. Можно попробовать один из них сделать членом класса, все публичные методы этого класса продублировать в C и пробросить их в член класса. Не помню, как такой трюк называется, но судя по всему, именно его и следует здесь применить.

MFC - это отдельная песня, фреймворк был написан в те времена, когда компилятор ещё не умел RTTI и поэтому содержит свои костыли, которым, как я понимаю, важен этот порядок.

Это криворучки из M$ постарались.

В MFC множественное наследование использовать нельзя. Для кого документацию вообще пишут?

ну вообще-то как бы можно http://msdn.microsoft.com/en-us/library/62x3wzxy(v=vs.80).aspx

что подразумеваешь под композицией?

в твоем случае A и B не являются потомками base что меня не устраивает. Для меня base это API, а der1 и der2 - реализации базового функционала.

Вот так лучше действительно не делать, имея общую базу для der1 и der2. Это если коротко. Если нужны подробности - пиши, расскажу.

рассказывай

Вопрос в том, зачем класс С наследует der1 и der2. Можно попробовать один из них сделать членом класса, все публичные методы этого класса продублировать в C и пробросить их в член класса. Не помню, как такой трюк называется, но судя по всему, именно его и следует здесь применить.

класс base определяет API. множество его потомков делятся на три группы: группа A имеет общую реализацию половины методов базового класса, группа B имеет общую реализацию другой половины методов базового класса, а третья группа имеет реализацию состоящую из общих частей группы А и группы B. Поэтому общую часть реализации методов для группы A я сделал в классе der1, для группы B в классе der2 а как быть с группой C я никак не могу определится.

В общем случае часть базы может изменятся классами der1 или der2, как реакция на работу самого класса. При этом множество всех непротиворечивых состояний для der1 вполне может не совпадать с множеством непротиворечивых состояний для der2.

В случае множественного наследования ты получаешь две базы, каждая из которых находится в некотором состоянии. При этом нужно постоянно следить за тем, чью именно базу ты используешь, чтобы не получить epic fail с чужой базой, которая не подходит для работы.

В подобных случаях лучше все же вынести интерфейсы ider1 и ider2, сами классы унаследовать через приватные члены и «пробросить» все функции интерфейсов в классы.

Чем чревато использование множественного наследования? (комментарий)

Если путанно объясняю - стукни в жаббер, там смогу подробнее расписать. мой ник " жаббер.ру

Ипать вы плюсоводы извращенцы...

PS: если вам требуется множественное наследование, есть мнение что у Вас что-то не так с архитектурой.

Главное не кури не наследуй классы с реализациями методов.

Если вам требуется множественное наследование, есть мнение что у Вас что-то не так с архитектурой.

100 раз эту мантру слышал от неосиляторов множественного наследования.

Какие-нибудь обоснованные подтверждения этой фразы вообще существуют?

Чревато ООП головного мозга.

классическое наследование в большинстве случаев не нужны, а вот миксины нужны, во всяком случае я так считаю.

почему? и какие альтернативы?

Поэтому общую часть реализации методов для группы A я сделал в классе der1, для группы B в классе der2 а как быть с группой C я никак не могу определится.

А зачем вам собственно класс base нужен? Ну определите часть api в der1, часть в der2 и объедините их в C. Сейчас у вас получается полная фигня. Наследование означает, что везде где используется base, можно использовать der1, а у вас он реализует только часть api, что концептуально не верно.

кажется ты немного не понял. У меня API одно, но классы имеют -частично общую реализацию.