Полиморфизм времени выполнения vs , полиморфизм времени компиляции

[Flex Ferrum]

Суть проблемы и, собственно, "холивара" в следующем.
В настоящее время в объектно-ориентированных языках (С++, С#, Delphi, Java) широко распространен первый тип полиморфизма, обеспечиваемый неследованием классов и интерфейсов и виртуальными методами. Стыковка и окончательная "сборка" функционала происходит во время выполнения за счет создания конкретных классов, реализующих нужные стратегии. Но (в последние несколько лет) в С++ получает все более широкое распространение т. н. полиморфизм времени комплияции, обеспечиваемый шаблонами. В этом случае стыковка и подстройка функционала может производиться еще на этапе компиляции, освобождая время выполнения для других задач. По сути - в большинстве случаев это реализация того-же паттерна "стратегия", но выбор и подгонка кода под выбранную стратегию происходит еще во время компиляции программы.
Так вот, было высказано мнение, что полиморфизм времени компиляции не обеспечивает должной гибгости (а потому и слабо применим в промышленной разработке), т. к. на этапе компиляции невозможно делать предположений о конкретном окружении, в котором будет работать откомпилированная программа, а потому статический выбор стратегий делает программу излишне монолитной.
С какой-то точки зрения это действительно так (если пользоваться compile-time-стратегиями бездумно), но с другой стороны - стратегии и полиморфизм времени компиляции - еще одна степень свободы и уровень обощенности кода, применимые в тех случаях, когда решение о выборе стратегии может быть принято на этапе компиляции, и переносить принятие такого решения в рантайм - излишнее усложнение задачи.

Хотелось бы услышать мнение многоуважаемой публики на этот вопрос, а также, по возможности, рассмотреть конкретные примеры и антипримеры.

[Бобёр]

Что то мне подсказывает, что по настоящему война здесь жаркой не будет.
Но! Замечу, что предпочитаю всё что можно делать в compile-time. Но вот полиморфизм - по старинке. В ран-тайме.

[trainer]

Цитата Flex Ferrum @ 07.09.05, 14:35

т. к. на этапе компиляции невозможно делать предположений о конкретном окружении, в котором будет работать откомпилированная программа

Это не всегда так. Например, список полей(их типы) в таблицах БД обычно статичен. Соответственно, зачем тащить с собой в run-time лишнюю работу, связанную с полиморфизмом времени выполнения? Результат - рост производительности в ~2.5 раза.

[Ivan_Govnoff]

Ну это как обычно, есть крайности, есть золотая середина. После прочтения GoF внутренне хочецца делать все классы абстрактными и везде втыкать паттерны, как там один из авторов цитировал письмо читателя в какой-то эхе: "мы уже применили в нашем проекте 20 паттернов из 25 описанных в вашей книге, подскажите, куда можно воткнуть остальные пять?" После прочтения Александреску и его друзей хочется везде пихать compile-time стратегии и трейтсы.

У статического полиморфизма, правда, есть еще минусы -- с ним сложнее обеспечить слабое связывание объектов, читабельность кода страдает во многих случаях, время компиляции растет. При том что в большинстве (я бы сказал даже -- в подавляющем большинстве) случаев это реально никакого практического выигрыша не дает.

Поэтому ИМХО статический полиморфизм -- штука в принципе хорошая и красивая, иногда даже незаменимая -- но не для широкого применения.

[Бобёр]

Да, Александреску - это хорошо. Но вот какое мнение я услышал от разных очень уважаемых мною людей:
"..следовать рекомендациям Александреску - прекраснейший способ загубить весь проект на корню". Уверен, что они знают, о чём говорят

[Flex Ferrum]

Цитата BugHunter @ 07.09.05, 18:59

Да, Александреску - это хорошо. Но вот какое мнение я услышал от разных очень уважаемых мною людей:
"..следовать рекомендациям Александреску - прекраснейший способ загубить весь проект на корню". Уверен, что они знают, о чём говорят

У меня создалось впечатление, что Александреску с Саттером тоже знают - о чем пишут.

Цитата Ivan_Govnoff @ 07.09.05, 18:48

У статического полиморфизма, правда, есть еще минусы -- с ним сложнее обеспечить слабое связывание объектов, читабельность кода страдает во многих случаях, время компиляции растет. При том что в большинстве (я бы сказал даже -- в подавляющем большинстве) случаев это реально никакого практического выигрыша не дает.

А вот тут уже лучше на конкретных примерах.

[Ivan_Govnoff]

Цитата BugHunter @ 07.09.05, 18:59

Да, Александреску - это хорошо. Но вот какое мнение я услышал от разных очень уважаемых мною людей:
"..следовать рекомендациям Александреску - прекраснейший способ загубить весь проект на корню". Уверен, что они знают, о чём говорят

Александреску ничего не пишет про проекты с высокоуровневой точки зрения, его книжка -- сборник интересных приемов на C++, не более того, просто прежде чем что-то из них применять надо думать головой, а стоит ли -- конечно, любые упражнения в Advanced C++ ради них самих вряд ли приведут к чему-то хорошему.

Цитата Flex Ferrum @ 07.09.05, 19:31

А вот тут уже лучше на конкретных примерах.

Насчет читабельности -- конечно ИМХО, но.... Скажем шаблон -- настолько абстрактная вещь, с первого взгляда совершенно непонятно, на что влияет параметр шаблона. Понятно только что что-то параметризуется А уж сами шаблоны... Кто видел исходники буста или stl, понимает о чем я. Причем для библиотек-то (написал и забыл) всё очень даже хорошо, но вот если у тебя само "мясо" проекта на них -- рефакторить, отлаживать и вообще читать это, согласись, тяжело.

Насчет слабого связывания -- ну тут я мож немного неудачно выразился... Просто механизм run-time полиморфизма менее завязан на каких-то фичах языка, а тут приходится предполагать, что, дескать, у класса который будет параметром шаблона должен быть перегруженый оператор "+", что ты к нему специализируешь какой-нибудь там класс трейтов, часто бОльшие ограничения накладываются на поведение класса... Это всё не относится, конечно, к простым случаям.. А в случае обычного, run-time полиморфизма, интерфейс как-то проще задать, требования к реализации как-то более явно видны обычно.

Что касается времени компиляции -- понятное дело, оно увеличивается неслабо, если у тебя шаблоны ВЕЗДЕ -- PCH не спасают.

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

[Бобёр]

Цитата

У меня создалось впечатление, что Александреску с Саттером тоже знают - о чем пишут.

то, что пишут Александреску с Саттером, Джэф Элджер - это прекрасно. Это полезно знать. Но.
1) для простого кодера это довольно бесполезно: все необходимые родительские классы и шаблоны как правило, уже созданы. Для того, что бы сделать НЕЧТО, обычно достаточно просто унаследоваться от правильных классов, перечень которых зависит от опытности программиста.
2) для разрабочиков шаблонов тоже довольно бесполезное чтиво: ещё неизвестно, каков уровень пользователей библиотек. Яркий пример - boost. Библиотека замечательная, но 80% (а может быть и больше) С++ программистов элементарно не способны даже просто понять проблем, которые эта библиотека (успешно) решает. Тот же STL с его алгоритмами. Штука замечательная, но как только дело доходит до bind-еров и т.п., земля, как правило, уходит из под ног.
Использование чего то сложнее sort, find_if-а приводит к плохо читаемому коду.
Не нужно говорить, что я лаймер. Я - обычный.

Очень многие проблемы обычно решаются хотя и менее элегантно, зато более надёжно. Надёжно с разных точек зрения.
Надёжность - вот краеугольный камень разработки ПО, и второй - поддерживаемость. Многие библиотеки могут похвастаться первым, но не вторым, и это плохо. Когда я смотрю на исходники STL или boost я как правило задумываюсь: "Наверное, это писали роботы "

Чтение Александреску сотоварищи очень полезно разрабочикам библиотек, а их, согласитесь, довольно мало. Немного можно назвать хорошо спроектированных и полезных библиотек.

[Flex Ferrum]

Цитата Ivan_Govnoff @ 07.09.05, 20:52

Александреску ничего не пишет про проекты с высокоуровневой точки зрения, его книжка -- сборник интересных приемов на C++, не более того, просто прежде чем что-то из них применять надо думать головой, а стоит ли -- конечно, любые упражнения в Advanced C++ ради них самих вряд ли приведут к чему-то хорошему.

Видимо, я его невнимательно читал... Он еще в предисловии пишет - в этой книге сделана попытка реализовать ряд паттернов из GoF на шаблонах С++. Или паттерны не имеют никакого отношения к промышленной разработке? А! Я понял! Ты мне предлагаешь всякий раз реализовывать абстрактные фабрики, синглетоны, умные указатели, менеджеры памяти для мальеньких объектов и т. д. и т. п. Видимо в этом и есть суть промышленной разработки - все с нуля! Никакого обобщения и повторного использования! Ура велосипедам!
Понятно, что вместо его Loki в подавляющем большинстве случаев можно использовать boost, ибо в большая часть того, что есть в Loki, есть и в бусте. Но таких вкусностей, как AbstractFactory, Singleton, Factory в бусте пока нет. А в разработке именно эти шаблоны используются довольно часто.

Цитата Ivan_Govnoff @ 07.09.05, 20:52

Кто видел исходники буста или stl, понимает о чем я. Причем для библиотек-то (написал и забыл) всё очень даже хорошо, но вот если у тебя само "мясо" проекта на них -- рефакторить, отлаживать и вообще читать это, согласись, тяжело.

А это, знаешь ли, как писать. Структурирование кода - головная боль любого программиста. У меня сложилось впечатление, что исходники того же STL (по структуре и стилю) не менялись с момента первой версии этой библиотеки, хотя и в ее исходниках есть своя логика. Согласен - код STL сложночитаем. С бустом в этом отношении дела обстоят получше. Там есть некоторые соглашения по структурированию кода, разнесения его по пространствам имен и т. п., так что разобраться в его потрохах несколько проще.
Но что мы имеем с другой стороны? Спагетти из классов с похожими именами, но реализующими базовую функциональность каждый по своему. Я (в одной из соседних веток) предложил реализовать обобщенную реализацию геометрического понятия "Точка" и "Прямоугольник" для произвольного типа координат и произвольного их количества. Какое количество классов мы будем иметь при реализации на шаблонах, и какое - при реализации с использованием runtime-полиморфизма?

Цитата Ivan_Govnoff @ 07.09.05, 20:52

Просто механизм run-time полиморфизма менее завязан на каких-то фичах языка, а тут приходится предполагать, что, дескать, у класса который будет параметром шаблона должен быть перегруженый оператор "+", что ты к нему специализируешь какой-нибудь там класс трейтов, часто бОльшие ограничения накладываются на поведение класса... Это всё не относится, конечно, к простым случаям..

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

Цитата Ivan_Govnoff @ 07.09.05, 20:52

А в случае обычного, run-time полиморфизма, интерфейс как-то проще задать, требования к реализации как-то более явно видны обычно.

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

Цитата BugHunter @ 07.09.05, 21:04

1) для простого кодера это довольно бесполезно: все необходимые родительские классы и шаблоны как правило, уже созданы. Для того, что бы сделать НЕЧТО, обычно достаточно просто унаследоваться от правильных классов, перечень которых зависит от опытности программиста.

Цитата BugHunter @ 07.09.05, 21:04

2) для разрабочиков шаблонов тоже довольно бесполезное чтиво: ещё неизвестно, каков уровень пользователей библиотек. Яркий пример - boost. Библиотека замечательная, но 80% (а может быть и больше) С++ программистов элементарно не способны даже просто понять проблем, которые эта библиотека (успешно) решает. Тот же STL с его алгоритмами. Штука замечательная, но как только дело доходит до bind-еров и т.п., земля, как правило, уходит из под ног.

Ну да, как обычно работает правило 80/20. 80% кодеров используют 20% возможностей своего инструментария...
Тут опять же, надо определиться - к чему мы стремимся? К тому, чтобы любой "студент-первокурсник", только-только прочитавший книгу "Язык ... за 21 день", мог писать высокотехнологичные программы, или к повышению уровня профессионализма сообщества программистов? Вон, посмотри на посты некоторых участников - на форуме уже не первый год, а до сих пор приходится объяснять прописные истины (ссылки могу дать в привате, дабы никого не дескредитировать). Это, по твоему, правильно? Куда мы с таким подходом придем? (из несколько другой области) понравилась фраза автора книги "Видеоэкология", написавшего про современное дачестроительство: "видимо, мы на протяжении тысячелетий совершенствовали технологии обработки дерева только для того, чтобы в итоге обшивать вновьпостроенные дачные дома одноорбазной вогонкой". А теперь съездий, например, в Кострому и посмотри на образцы деревянного зодчества начала 2-го тысячелетия. Для сравнения .

[Бобёр]

Цитата

Никакого обобщения и повторного использования! Ура велосипедам!

читай мою подпись

[Flex Ferrum]

Цитата BugHunter @ 08.09.05, 08:06

Никакого обобщения и повторного использования! Ура велосипедам!

читай мою подпись

Цитата BugHunter @ 08.09.05, 08:06

Каждый из нас должен сделать ЭТО, хотя колесо уже изобрели

Прочитал. Так вот - смотря с какой целью и на каком уровне. Если в результате получится точно такое же колесо, или велосипед в том виде, в котором он был придуман в 19-ом веке - то и браться было незачем (если только это не делалось в целях самообразования). А если получится что-то новое и полезное - то, бесспорно, ЭТО того стоило.

[Бобёр]

А ссылочки в приват давай. Что бы никого не компроментировать. Кстати, я ожидаю там увидеть и свои посты

[Ivan_Govnoff]

Цитата Flex Ferrum @ 08.09.05, 07:42

Цитата Ivan_Govnoff @ 07.09.05, 20:52

Александреску ничего не пишет про проекты с высокоуровневой точки зрения, его книжка -- сборник интересных приемов на C++, не более того, просто прежде чем что-то из них применять надо думать головой, а стоит ли -- конечно, любые упражнения в Advanced C++ ради них самих вряд ли приведут к чему-то хорошему.

Он еще в предисловии пишет - в этой книге сделана попытка реализовать ряд паттернов из GoF на шаблонах С++. Или паттерны не имеют никакого отношения к промышленной разработке? А! Я понял! Ты мне предлагаешь всякий раз реализовывать абстрактные фабрики, синглетоны, умные указатели, менеджеры памяти для мальеньких объектов и т. д. и т. п. Видимо в этом и есть суть промышленной разработки - все с нуля! Никакого обобщения и повторного использования! Ура велосипедам!

Интересно, где ты увидел призыв про "все с нуля" в моем посте? Или про то что шаблоны Александреску "не имеют отношения к промышленной разработке"??? Я просто ответил на реплику BugHunter'а -- ИМХО использование Александреску не может ни загубить, ни спасти никакой проект.

Цитата Flex Ferrum @ 08.09.05, 07:42

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

Ну да, можно долго приводить примеры где лучше тот или иной вариант... Тока вот "точка", "вектор" -- это не пример из каждодневной практики, это пишется один раз и навсегда. Для библиотек полиморфизм на шаблонах подходит замечательно, я не спорю.

Кстати не согласен с этим:

Цитата BugHunter @ 07.09.05, 21:04

Яркий пример - boost. Библиотека замечательная, но 80% (а может быть и больше) С++ программистов элементарно не способны даже просто понять проблем, которые эта библиотека (успешно) решает.

ИМХО тут циферка далека от 80%, если не считать за С++ программистов людей которые могут написать на C++ чуть больше чем "hello world". Огромное количество людей использует буст.

[x0ras]

Цитата Flex Ferrum @ 08.09.05, 07:42

У меня сложилось впечатление, что исходники того же STL (по структуре и стилю) не менялись с момента первой версии этой библиотеки, хотя и в ее исходниках есть своя логика. Согласен - код STL сложночитаем.

Это от реализации зависит. Например, STL от SGI имеет очень красивые исходники. По крайней мере, мне ничего не стоило в них разобраться.

Цитата Flex Ferrum @ 08.09.05, 07:42

Видимо в этом и есть суть промышленной разработки - все с нуля! Никакого обобщения и повторного использования! Ура велосипедам!

Не всегда есть возможность повторного использования. Да и без собственных велосипедов тоже сложно.

Цитата Flex Ferrum @ 08.09.05, 07:42

Тут опять же, надо определиться - к чему мы стремимся? К тому, чтобы любой "студент-первокурсник", только-только прочитавший книгу "Язык ... за 21 день", мог писать высокотехнологичные программы, или к повышению уровня профессионализма сообщества программистов?
/* ... */
Это, по твоему, правильно? Куда мы с таким подходом придем?

Flex, мы-то к этому не стремимся. Только Microsoft делает все возможное, чтобы претворить мой кошмарный сон в реальность.

Цитата Flex Ferrum @ 07.09.05, 14:35

Хотелось бы услышать мнение многоуважаемой публики на этот вопрос, а также, по возможности, рассмотреть конкретные примеры и антипримеры.

А какой вопрос-то? Ты сам в своем первом сообщении написал все плюсы и минусы.

[Flex Ferrum]

Цитата Ivan_Govnoff @ 08.09.05, 08:26

Интересно, где ты увидел призыв про "все с нуля" в моем посте? Или про то что шаблоны Александреску "не имеют отношения к промышленной разработке"??? Я просто ответил на реплику BugHunter'а -- ИМХО использование Александреску не может ни загубить, ни спасти никакой проект.

В это контексте - да. Согласен. Ибо "все у нас в голове".

Цитата Ivan_Govnoff @ 08.09.05, 08:26

Ну да, можно долго приводить примеры где лучше тот или иной вариант... Тока вот "точка", "вектор" -- это не пример из каждодневной практики, это пишется один раз и навсегда. Для библиотек полиморфизм на шаблонах подходит замечательно, я не спорю.

А для конечных проектов шаблонный полиморфизм (на мой взгляд) подходит еще больше. Ибо одна из проблем, которая должна быть решена для библиотеки - это уменьшение связности кода. Для конкретного проекта эту проблему решить проще. Да и возьми, например, тот же Visitor или Multimethod. Эти шаблоны завязаны именно на конкретный набор типов, пусть даже и передающийся с помощью соответствующих списков.
Потом, только принятие решения об использовании статического полиформизама оказывает существенное влияние на дизайн и структуру классов проекта.

Цитата x0ras @ 08.09.05, 09:20

Не всегда есть возможность повторного использования. Да и без собственных велосипедов тоже сложно.

Если их создание оправданно теми или иными критериями.