Я совершенно согласен с вами что это решается , но в языке есть четкая потдержка наследования реализации через ромбовидное наследование (виртуальное). Этому методу посвящена глава из страуструпа , я не вижу вообще преимуществ других решений перед этим.

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

C>vdimas wrote:
>> C>Ну как бы оно тоже считается "статическим полиморфизмом".
>> Офигеть.
>> В этом случае все элементы статически-типизированных языков претендуют
>> на статический полиморфизм.
>> Например:
>> operator+(int, int)
C>Нет, не все.

Например?

C>Язык С

Язык С — слабо статически типизирован. Например, он автоматом переводит все типы указателей друг к другу.

Вопрос остается. Мне считать operator+(int, int) проявлением статического полиморфизма?

(на всякий случай напомню мое мнение: статический полиморфизм — это сленг)

vdimas wrote:
>> > В этом случае все элементы статически-типизированных языков претендуют
>> > на статический полиморфизм.
>> > Например:
>> > operator+(int, int)
> C>Нет, не все.
> Например?
Я же сказал, Паскаль — это статически типизированый язык (поспоришь?),
но в нем запрещена статическая перегрузка. То есть не может быть двух
функций с одним именем, но с разным набором параметров.

> Вопрос остается. Мне считать operator+(int, int) проявлением
> статического полиморфизма?
Да, если возможен operator +(MyObject,int).

> (на всякий случай напомню мое мнение: статический полиморфизм — это сленг)
Он упоминается в книгах Страуструпа, так что это уже термин

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

C>Я же сказал, Паскаль — это статически типизированый язык (поспоришь?),
C>но в нем запрещена статическая перегрузка. То есть не может быть двух
C>функций с одним именем, но с разным набором параметров.

>> Вопрос остается. Мне считать operator+(int, int) проявлением
>> статического полиморфизма?
C>Да, если возможен operator +(MyObject,int).

Если в языке есть неявное приведение short int -> int, то оператор + (int, int) полиморфен. Но это не универсальный полиморфизм, а ad-hoc. Точно также как и перегрузка. Поэтому и Паскаль все-таки нельзя назвать полностью мономорфным языком.

B>Вот ответьте мне опытные, зачем отказались от множественного наследования ?

У меня есть одна крамольная мысль, которая может это объяснить.
Во времена "гонки жаб" (когда мелкомягкие пытались сделать "почти такую же", но свою JDK), была наработана куча кода, которая сделала своё чёрное дело (windows-native несовместимость), после чего была с почётом похоронена. Впоследствии, учтя то, что писать на MFC невозможно, а бабки нужно зарабатывать, решили из двух недостатков (недожабы и недобиблиотеки) сделать один достаток — якобы "новую" архитектуру! То бишь банально взять JVM с библиотеками и засунуть в каталог Windows, назвав всё это "многоплатформенной .NET". Разумеется, махать позорными плакатиками с Жабой было уже как-то стыдно, поэтому исходники побырому переделали и назвали жабу "си-диезом". Обратите внимание на синтаксис этих языков — да он почти неотличим! А виртуальная машина? Тот же стековый аппарат, JIT, классы...
Отсюда и ответ: да просто лень было заморачиваться! Есть уже работающая, ОДНОНАСЛЕДУЕМАЯ жаба — чего зря напрягаться?...


B>Можно ли все случаи и возможности множ.наследования в проектировании решить с одним одиноночным и n колличеством интерфейсов ?

Разумеется, НЕТ! Множественное наследование смешивает ФУНКЦИОНАЛЬНОСТЬ, а интерфейсы лишь диктуют контракт общения между классами.


Кто-то тут уже высказывал мысль, мол "МН даёт неуправляемую смесь классов". А я скажу больше — уже само наследование есть ничто иное, как смешивание в кучу своих членов и членов родителя! Это ли не есть бардак?

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

Q>Разумеется, НЕТ! Множественное наследование смешивает ФУНКЦИОНАЛЬНОСТЬ, а интерфейсы лишь диктуют контракт общения между классами.

Функциональность можно смешать не только наследованием.

Q>Кто-то тут уже высказывал мысль, мол "МН даёт неуправляемую смесь классов". А я скажу больше — уже само наследование есть ничто иное, как смешивание в кучу своих членов и членов родителя! Это ли не есть бардак?

ты недосмотрел высказанные мысли — тут были так же мысли, что и одиночное наследование дает бардак и лучше ограничиться только интерфейсами.

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

Al_>А как ты можешь их видеть, если вся твоя история прошла в этом мире, мире физики, мире природы?! ты по другому просто не можешь.

Вот например, в природе есть слон. В программе мы можем смоделировать слона. Пользователю программы может потребоваться список слонов, у которых уши более чем на 2% меньше среднего среди слонов вообще. Для реализации тебе потребуется объект — массив слонов. Что такое массив слонов? В мире нет такого объекта. А если бы был, то он обтягивал бы почти весь земной шар, т.к. слоны с отклонениями есть на разных континентах.

Al_>У тебя нет такого опыта и быть не может.

Какой физический смысл у массива любых объектов? Откуда такой странный опыт — массив, как людям удалось такое придумать?

Какой физический смысл у объектов-оберток? Что моделирует объект, который существует лишь из-за технического ограничения — часть кода должна была быть написана на другом ЯП? Ему даже название трудно придумать, он ничего не делает, он ничего не представляет, просто в вашей реализации ЯП это оказался единственный способ. Так вот веришь-нет, из таких объектов, которые изначально ничего из природы не моделируют, можно строить целые системы, которые будут делать то, что тебе нужно.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Al_, Вы писали:

Al_>>А как ты можешь их видеть, если вся твоя история прошла в этом мире, мире физики, мире природы?! ты по другому просто не можешь.

Кё>Вот например, в природе есть слон. В программе мы можем смоделировать слона. Пользователю программы может потребоваться список слонов, у которых уши более чем на 2% меньше среднего среди слонов вообще. Для реализации тебе потребуется объект — массив слонов. Что такое массив слонов? В мире нет такого объекта. А если бы был, то он обтягивал бы почти весь земной шар, т.к. слоны с отклонениями есть на разных континентах.

Al_>>У тебя нет такого опыта и быть не может.

Кё>Какой физический смысл у массива любых объектов? Откуда такой странный опыт — массив, как людям удалось такое придумать?
Да коробок спичек, например. НАБОР любых условно-ОДНОРОДНЫХ объектов. Вполне реальный объект.

Кё>Какой физический смысл у объектов-оберток? Что моделирует объект, который существует лишь из-за технического ограничения — часть кода должна была быть написана на другом ЯП? Ему даже название трудно придумать, он ничего не делает, он ничего не представляет, просто в вашей реализации ЯП это оказался единственный способ. Так вот веришь-нет, из таких объектов, которые изначально ничего из природы не моделируют, можно строить целые системы, которые будут делать то, что тебе нужно.
Не хотел бы я работать с такой системой. В ней черт ногу сломит. Как можно воспевать подобную архитектуру?! Небывет "единственных" реализаций всегда есть варианты. Архитектора под суд!

У меня создается впечатление, что говорю с человеком, который пишет аморфный код, не деля его на логические части. Это напоминает студентов, которые вырезают куски кода из написанной ими мешанины и помещают их в подпрограммы — делают это они только потому, что в требовании к работе указано на необходимость использования подпрограмм.

Системы с объемом исходного кода порядка десятков тысяч строк будут более понятны для восприятия сторонним программистам, если большая часть архитектуры размещена в осмысленных объектах. Или представь аналогичную систему с твоими вымышленными объектами Сколько надо времени, чтобы понять что и как каждый объект делает?! Ведь все равно весь код изучить неудастся, но в первом случае ты априорно сможешь домыслить некоторые вещи... во втором только изучать код Да и полную картину увидеть проще.

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

Кё>>Какой физический смысл у массива любых объектов? Откуда такой странный опыт — массив, как людям удалось такое придумать?
Al_>Да коробок спичек, например. НАБОР любых условно-ОДНОРОДНЫХ объектов. Вполне реальный объект.

Коробок спичек, это просто удобный частный случай. Расскажи лучше про смысл массива слонов, который необходим чтобы listview мог отобразить произвольную выборку индивидов. Или про массив всех спичек некоторого завода за 2005-й год, у которых отсутствует головка (брак). Где у них соответствующий реальный объект?

Кё>>Какой физический смысл у объектов-оберток? Что моделирует объект, который существует лишь из-за технического ограничения — часть кода должна была Al_>Не хотел бы я работать с такой системой. В ней черт ногу сломит.

А тебя не спрашивают, что бы ты хотел. Когда в системе есть библиотека А, которая использует std::string, и есть библиотека Б, которая использует MyFooString, тебе нужно написать пару "бессмысленных" функций и оберток чтобы их данные свободно передавались между объектами библиотек. Эти пара непонятных функций нужны чтобы остальные 90% системы сделать читабельными, прозрачными и понятными.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Al_, Вы писали:

Кё>>>Какой физический смысл у массива любых объектов? Откуда такой странный опыт — массив, как людям удалось такое придумать?
Al_>>Да коробок спичек, например. НАБОР любых условно-ОДНОРОДНЫХ объектов. Вполне реальный объект.

Кё>Коробок спичек, это просто удобный частный случай. Расскажи лучше про смысл массива слонов, который необходим чтобы listview мог отобразить произвольную выборку индивидов.
В зоопарке есть N слонов, каждый со своим инвентарным номером. Даже где-то в бухгалтерии они значатся. А вообще я не любитель массивов — предпочитаю списки очереди и пр...

Кё>Или про массив всех спичек некоторого завода за 2005-й год, у которых отсутствует головка (брак). Где у них соответствующий реальный объект?
Ну приведу я тебе щаз пример... что это изменит? Ветку — в священные войны — там глядишь и народ подключится

Кё>>>Какой физический смысл у объектов-оберток? Что моделирует объект, который существует лишь из-за технического ограничения — часть кода должна была Al_>Не хотел бы я работать с такой системой. В ней черт ногу сломит.

Кё>А тебя не спрашивают, что бы ты хотел. Когда в системе есть библиотека А, которая использует std::string, и есть библиотека Б, которая использует MyFooString, тебе нужно написать пару "бессмысленных" функций и оберток чтобы их данные свободно передавались между объектами библиотек. Эти пара непонятных функций нужны чтобы остальные 90% системы сделать читабельными, прозрачными и понятными.
А представь, что у тебя 95% кода из таких "бессмысленных" функций . Куда щемиться будешь? В виде исключения могу допустить их присутствие в минимальном количестве, но право на их существование тщательнейшим образом обдумаю.