Современный дизайн С++

[lapulya]

А что такое статический полиморфизм (от одного словосочетания меня бросает в жар)? Видать в развитии С++ я чего то упустил? Где про это почитать?

[Антон (LogRus)]

lapulya, шаблоны и всё такое

примеры
std::vector
std::sort
std::auto_ptr
boost::shared_ptr

потом всякие: стратегии(policy), свойства(traits) и т.п.
На тему рекоменду книгу: Александреску "Современный дизайн С++"

[Dimka]

На тему рекоменду книгу: Александреску "Современный дизайн С++"

За такое расстреливать надо Не потому, что плохо работает, а потому что код получается совершенно нечитабельным, и ошибки компилятор выдаёт трёхэтажные.

Вот, допустим, кто-то написал некий довольно обширный модуль в духе Александреску, впечатлившись книжкой. Могу я посадить какого-нибудь зелёного программиста на сопровождение этого кода? Не могу, потому что он на 3-й строчке впадёт в уныние, а на 10-й у него начнётся депрессия: работу делать надо, а с какой стороны к этому подступиться - непонятно. Попытка любого изменения приводит к страшной ругани компилятора, в которой и не всякий опытный программист с первого взгляда разберётся и скажет, чего не так. Более того, зелёный программист не умеет так писать - это значит, что любое изменение модуля будет сделано в другом стиле, нередко в ущерб архитектуре, когда боятся, или не умеют, или не знают как пользоваться теми или иными приёмами, и начиают дублировать решения разными заглушками и всем прочим.

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

[Антон (LogRus)]

За такое расстреливать надо Не потому, что плохо работает, а потому что код получается совершенно нечитабельным, и ошибки компилятор выдаёт трёхэтажные.
................
................
Короче, все такие подходы, конечно, по-своему красивы, но где я вам возьму столько опытных разработчиков, которые умеют и хотят всем этим пользоваться? Как обеспечить многолетнее сопровождение такого кода?

У нас такой код посместно, и должен заметить что:
1. читаемость - улудшилась в разы
2. доработки упростились - т.к. кода стало меньше и он легко читаем
3. Нового программиста обучить раз плюнуть если посадить его работать в паре с корефеем
4. Шаблонами должен уметь пользоваться и начинающий, а хрень какая-то получается народ разрабатывает стандарты, что-то в языке улудшает, а все так и застряли в гибридном прошлом связки C и C++, нефиг есть язык используй его максимально

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

Я понимаю, что, если взять и начать все советы Александреску применять в лоб и везде, где только можно, что получится полная Ж(проверено), ну так голова нужна не шапку носить

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

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

Всё это очень быстро подтягивает уровень зелёных программистов почти до уровня кореефев, кроме то и сам корефей работая в паре перенемает опыт зелёных программистов, у нас были прицеденты, когда программисты без опыта работы, но с хорошей подготовкой, подтягивали весь коллектив. За что им лично от меня ОГРОМНОЕ СПАСИБО . просто ВОООООООООООООООООООТ такенское СПАСИБО.

Под хорошой подготовкой подразумевается вдумчивое чтение:
1. Основ C++ - Эккель, Срауструп, Липман
2. STL - Саттер, Мейерс
3. Приёмы программирования - Банда Четырёх, Саттер, Александреску
4. Шаблоны - Вандевуд и Джо Сьютис(Сатис)

[Вад]

Во многом согласен с LogRus-ом, многое зависит от организации процесса. Если экономить на обучении (видимо, как правило - экономить пытаются), то получается, что каждый владеет только тем, чего успел нахвататься, плюс перенимают от коллег что-то. Конечно, при таком подходе зелёных будет много, даже опытные разработчики не будут владеть многими средствами языка, потому что освоенных средств для сколько-нибудь эффективного решения хватает, то есть стимул применять новое невелик.
Чтобы было понятно, если я сейчас пойду к своему начальству и скажу по пунктам то, что предлагал LogRus, мне вернее всего по пунктам ответят:
1. А что, сейчас у вас проблемы с читаемостью? Лучше комментируйте код.
2. А надо сразу проектировать правильно и писать код, который потом не понадобится менять. (даже, возможно, согласятся, что это мало реально, но скажут, что так должно быть)
3. Нет у нас столько ресурсов сейчас, чтобы каждого новичка прикреплять к опытному.
4. Почему? Почти всегда без создания шаблонов обходились.

Конечно, я немного утрирую, но скорее всего, ответ будет довольно похожий. Могу специально по случаю провести эксперимент, а потом сообщить
Вообще же почему-то бытует стереотип, что обучение языку организовывать не надо - вроде, такая очевидная вещь. При этом литература, которая попадает в руки новичкам, бывает сильно заточена под новичков, а посему в ней упускаются многие существенные моменты и не расставляются нужные акценты (особенно если автор сам не силён в некоторых конструкциях языка). А в результате, у человека формируется несколько искажённое представление о языке, возможностях и подходах.

[Антон (LogRus)]

Хорошо, что у нас начальство, не только с этим не спорит, но продвигает некоторые практики XP

[sss]

LogRus про какие категории программирования ты говоришь? Организацию списков и их сортировку? И все? Или полностью обо всех сферах? Я имею ввиду моделирование поведения группы объектов с одинаковыми характеристиками. Например, модель рисования сцены из списка объектов. Проходя по списку рендер читает свойства объектов и рисует. Где здесь место статическому полиморфизму?

P.S.: Шаблоны автоуказателей во всю применяются в библиотеках COM. Вот пожалуй единственное место, где я видел применение шаблонов фирмой Microsoft. Или они то же новички. Жаль, ничего не знаю про коды Unix 

[Антон (LogRus)]

LogRus про какие категории программирования ты говоришь? Организацию списков и их сортировку? И все? Или полностью обо всех сферах? Я имею ввиду моделирование поведения группы объектов с одинаковыми характеристиками. Например, модель рисования сцены из списка объектов. Проходя по списку рендер читает свойства объектов и рисует. Где здесь место статическому полиморфизму?

Тут вобщето нет места но это, же единственный метод использовать полиморфизм
У меня таких задач не возникало не разу

Да и ваще просто обсуждаем что да как.

[sss]

Ну извини. Я в последнее время занимаюсь всякой фигней, вот и нервный 

[Антон (LogRus)]

Вот задачку вспомнил.

В коде используются различные типы мьютексов, из различных Third Party библиотек требуется реализовать, едино образный механиз использования мьютексов, что бы для изменения типа мьютекса требовалось поправить только параметр шаблона

Для этого сделали обёртку шаблонную со специализациями под различные мьютексы

переход с одного мьютекса на другой выглядит вот так:
строчку
typedef detail::lock_policy<tbb::mutex> mutex;
mutex mutex_;
меняем на
typedef detail::lock_policy<boost::mutex> mutex;
mutex mutex_;

блокировки в коде остаются не изменными:
mutex::read_lock lock(mutex_);
или
mutex::rw_lock lock(mutex_);

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

потестил производительность, мьютекс не устроил заменил одну строчку и всё.

[sss]

А если бы он был полиморфом? Ну переписал (перекрыл) один метод ? Хотя трудно спорить. Здесь берется поведение готового. Ну только не пойму, tbb::mutex и boost::mutex как реализованы? Имеют общий базовый класс?

[Антон (LogRus)]

sss, в общем да.

ну вот vector, sort, find яркие примеры

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

[sss]

Бес порно . Хотя, опять же, такое ( я про mutex) возможно при их полиморфизме или, что хуже по моему мнению, реализаций псевдополиморфизма. в общем истина где-то близко возле баланса...

Про раздувание кода - вообще молчу. Чуть немного изменяется тип, пожалуйста новая версия шаблона. Тема об правилах инстацирования шаблонов вообще лес  (для меня одного наверное).

Вот кстати еще один пример, когда я обламался. Прикольно погружать в векторы значения типа int, bool и т.д. Когда дело доходит до больших объектов, операций копирования становиться слишком много. И в конечном итоге, все списки начинают нести указатели на полиморфные объекты..

[Алексей++]

Вот задачку вспомнил.

а мне кажется, задачка легко решается макросами

[Антон (LogRus)]

Алексей1153++, как ты предсказуем

кстати не решается задачка.

[RXL]

LogRus, поясни. Примерчики, пожалуйста

[Dimka]

1. читаемость - улудшилась в разы

Смотря с чем сравнивать . Если с макросами, то - да. Если с другими языками программирования, то ещё очень далеко до совершенства .

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

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

[Алексей++]

LogRus, решается, легко. Примеров не проси - они точно есть, только я написать не смогу сходу А насчёт предсказуемости - знамо дело, использовать надо то, что проще всего применить

[Olegator]

Если с другими языками программирования, то ещё очень далеко до совершенства .

Тут я не понял. О чём речь?

[lapulya]

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

Шаблоны очень нужная вещь, без них никак нельзя (to sss, надо учиться понимать, не используя шаблоны эффективность написания кода сильно снижается, энто я тебе голуба говорю как краевед...), они придают огромную гибкость приложению, НО!!! никак, никогда не заменяли, не заменяют и некогда не заменят настоящий полиморфизм (это я про динамический полиморфизм). Шаблоны введены в язык совершенно для других целей

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

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

Ну все я уже остыл )))) Ругайте....

Кстати по поводу задачки... если бы это был динамический полиморфизм ))) я б тоже только одну строчку сменил, вот эту
IMutex * mutex = new TheOneMutex();
на эту
IMutex * mutex = new TheOtherMutex();
и более ничего, что никах не более того, что написал ты.

[lapulya]

to sss ты мне объясни зачем в контейнере хранить объект, а не ссылку на него? Какая цель?

[Finch]

lapulya, В лени, написать new Object(Object2); Например когда делаеш снапщот состояния, как хорошо и быстро v2[1]=Object; А что после этого еше паравоз кода пойдет по умолчанию. Так оно то и не видно.

Всего должно быть в меру. Если сверх меры применять, то это изврашение.

[Dimka]

Тут я не понял. О чём речь?

О том, что C++ проигрывает в синтаксическом изяществе языкам, более далёким от железа.

IMHO, вся эта параметризация (сиречь шаблоны, которые template в C++, generic в Ada и .NET 2.0 и выше) как явление - это попытка вырваться из ограничений, накладываемых жёсткой типизацией переменных в ряде языков программирования. С точки зрения читабельности кода - это шаг в сторону отказа от типизации; с точки зрения компиляции и отладки - это сохранение жёсткой типизации. Если решить вопрос по существу, у нас получится слаботипизированный или вообще нетипизированный язык, в котором параметризация полностью теряет смысл, равно как и наследование, и полиморфизм и всё прочее. Но вместе с тем мы также лишаемся элементарных проверок согласованности частей программы между собой, которые выполняет компилятор. Правда, и этот вопрос - решаемый за счёт внедрения практик модульного тестирования, совмещения процессов кодирования, исполнения и отладки программы в одном процессе разработки в развитой среде, наконец, синтаксис можно проверять автоматически.

P.S. А не перенесли ли тему в раздел "Технологии разработки программных систем"?

[Вад]

Вот задачку вспомнил.

В коде используются различные типы мьютексов, из различных Third Party библиотек требуется реализовать, едино образный механиз использования мьютексов, что бы для изменения типа мьютекса требовалось поправить только параметр шаблона

Для этого сделали обёртку шаблонную со специализациями под различные мьютексы

По-моему, Гамма с остальными тремя бандитами рекомендовал Third Party-библиотеки оборачивать на базе своего универсального интерфейса и прятать конструирование в фабрику. Хотя, конечно, если две библиотеки умеют ровно одно и то же...
lapulya,

IMutex * mutex = new TheOneMutex();
на эту
IMutex * mutex = new TheOtherMutex();

Вот именно поэтому в фабрику и надо заворачивать: ты этот код ведь не будешь во всех местах, где создаётся мьютекс, руками править?

dimka, я вот тоже подумываю перенести тему, но удерживает то, что уж очень она C++-специфична

[RXL]

P.S. А не перенесли ли тему в раздел "Технологии разработки программных систем"?

Нет проблем. Только там модератора нет. Ты бы согласился?

[Dimka]

Только там модератора нет.

И обсуждений тоже. Зачем там модератор?

Ты бы согласился?

Сторожем на кладбище... Ну что ж, должность тихая, необременительная.

[lapulya]

to Вад

lapulya,

IMutex * mutex = new TheOneMutex();
на эту
IMutex * mutex = new TheOtherMutex();

Вот именно поэтому в фабрику и надо заворачивать: ты этот код ведь не будешь во всех местах, где создаётся мьютекс, руками править?

Речь шла о задачке, а не о том как объект создавать, да и кто тебе сказал что я эти строчки не в фабрике меняю?

[sss]

Извините что молчал, в выходные интернет не использую...

to sss ты мне объясни зачем в контейнере хранить объект, а не ссылку на него? Какая цель?

Вопросом на вопрос, зачем мне контейнер-шаблон если я собираюсь хранить ссылки на объекты, т.е. указатели? Хорошо. Можно ответить - указатели на разные типы объектов. Но тогда тут же получаем множество версий кода контейнера, работающих с разнотипными указателями. При этом это всего лишь указатели и требуется одна версия.

Зачем же тогда нужны шаблоны? Возможно ты думаешь, что я ни хера не смыслю в этом, ну может это и так, тогда поправьте.... Короче. Зачем же тогда нужны шаблоны? Для того, что бы использовать математические операторы описанные для встроенных или пользовательских типов с описанными основными операторами +, - , >, <, =, ==.  Затем для таких типов можно написать шаблоны, в частности вектора, которые будут использовать эти операторы в своих методах, например сортировки. Одним словом, шаблон это использование хорошо известных, документированных, выверенных, сбалансированных методов для простых типов данных. Бог в помощь при написании своих библиотек шаблонов...

[Антон (LogRus)]

Привет комьюнити мой пост можно не читать ибо эмоционально получилось

Кстати по поводу задачки... если бы это был динамический полиморфизм ))) я б тоже только одну строчку сменил, вот эту
IMutex * mutex = new TheOneMutex();
на эту
IMutex * mutex = new TheOtherMutex();
и более ничего, что никах не более того, что написал ты.

А вот зачем мне эта штука времени выполнения? Я не собираюсь менять мьютексы в ходе выполнения программы.
Далее созданный мьютек валяется в куче неизвестно где, зачем мне подгружать в кэш дополнительные данные? Если сделать мьютекс членом класса, он уже будет подгружен вместе с самим классом.

Вопросом на вопрос, зачем мне контейнер-шаблон если я собираюсь хранить ссылки на объекты, т.е. указатели? Хорошо. Можно ответить - указатели на разные типы объектов. Но тогда тут же получаем множество версий кода контейнера, работающих с разнотипными указателями. При этом это всего лишь указатели и требуется одна версия.

Если ты хранишь указатели на интерфейс, куча реализаций(для каждого типа наследника) конечно тебе не нужна, а шаблон за тебя делает грязную работу по адаптации контейнера для твоего типа данных.

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

Ну не скажи. Вот написал я хиртое хранилище объектов, которое подгружает(само) данные из БД, предоставляет интерфейс для поиска, т.п. - этакий imdb(InMemoryDB). Я делаю его шаблоным со стратегиями и свойствами. Для чего, для того что бы мог подгружать различные объекты из БД(разичные SQL запросы, критерии поиска и т.п.).
Где тут полохо чего спроектировано? Я знаю, что НИКОГДА не буду приводить элементы хранилища и само хранилище к указателю на базовый тип, не пересекаются они никак, просто общий каркас, зачем мне виртуальные функции и прочее, а если вдруг понадобится ничто мне не помешает, сделать 2 в одном.
Или мне по всем правилам обязательно, использовать в своём конетейнере использовать указатель на базовый класс элементов, еще хранилище отнаследовать от чегонибуть, сделать кучу наследников под каждый тип?
А теперь представим, что я делаю поиски в этом хранилище 10000 раз в секунду, почему каждый раз я должен тратить процессорное время на полиморфиз, если у меня требование к системе обрабатывать 100000 запросов в секунду.

Так, что не вижу ни каких причин называть

динамический полиморфизм это инструмент проектирования

, а шаблоны

шаблоны это инструмент реализаци

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

для разрядки:
1: У меня гугл не открывается...
2: Лампочка на модеме горит?
3: Да. Только это не лампочка, а теристорный светодиод
4: Гм... Да, пожалуй, проблемы на нашей стороне...
(стырино с bash.org.ru)

[sss]

Не хотел отвечать, отвечу...

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

Допустим встречаю ситуацию - тормозит! Офигеть!  Начинаю разбираться - оказывается это расходы на полиморфизм! Веришь?

P.S.: Прошу прощения за иронию, не смог удержаться. 

[Антон (LogRus)]

sss, не верю но я не обязан платить за услугу которая мне не нужна
так же как за RTTI

[sss]

Согласен. Просто я наверное уже закостенелый реликт, der neue gott...

[Dimka]

Начинаю разбираться - оказывается это расходы на полиморфизм!

В критических по времени исполнения приложениях это может быть именно так Хотя в большинстве случаев это совсем не так.

[Not]

Начинаю разбираться - оказывается это расходы на полиморфизм! Веришь?

Точное замечание. Прогулки по виртуальным таблицам увы небесплатны. Если важна скорость работы приложения, то статический полиморфизм - великолепная вещь. Если нужна гибкость объектной модели - динамический лучше. Все зависит от задачи.

[sss]

Интересно, что значит "прогулки по виртуальным таблицам"? Таблица существует в памяти, и по ней никто не гуляет. Просто адрес вызова берется из нее по смещению.

[Dimka]

sss, это значит, что до вызова функции нужно ещё во время исполнения прочитать её адрес из таблицы - дополнительная операция.

[npak]

У меня провокационный вопрос. А где нужно (действительно нужно и очень оправдано) использовать С++?

В наше время почти бесконечно дешевого железа языки Java и .Net дают вполне приличное быстродействие на офисных/финансовых задачах. Есть даже примеры разработки ядер операционных систем на таких языках (если память не изменяет, сборка мусора в ядре поддерживается в Plan9).

Бешеное быстродействие нужно во встроенных системах с жестким реальным временем, но даже для таких систем есть ОО язык Eiffel с поддержкой сборки мусора.

я в последнее время пишу преимущественно на связке Java+C, причем стараюсь как можно больше запихнуть в Джаву, и свести использование С к минимуму.

Так зачем вы используете С++? Для того, чтобы не искушать начальство, ибо сильно умных не любят?

[Антон (LogRus)]

npak, зачем холивары провоцируем? хотя конечно стоит задуматься может и переписать кое-что.

что касается сборки мусора, то в современном C++ это скорее вопрос дисциплины, чем реальная проблема умные указатели вполне справляются с возложенной задачей, а сочетании с пул аллокаторами дают очень приличную производительность в операциях с постоянным выделением/удалением памяти.

[Алексей++]

Так зачем вы используете С++? Для того, чтобы не искушать начальство, ибо сильно умных не любят?

а если мне просто тупо красиво ? вкусно ? И тошнит от шарпов.
Кстати, вот Инге тока шо казал - моему начальству глубоко наплевать, на чём у него программисты пишут, лишь бы работало хорошо

----
кстати, пробовал щас поставить студию 2008 - не вышло, плохая пиратская копия, не сломали . Поставилась 2005. Если новый проект буду начинать - там буду делать. В MFC

[RXL]

Леш, а меня от C++ тошнит с его наворотами. Хотя и пишу на нем...

LogRus, тебе хорошо - ты на бустах руку набил, а для меня он как бред выглядит

Куда легче на Perl программить.

[McZim]

RXL, кому что Меня от Perl и Bash воротит

[Алексей++]

вот. Всем разное нравится. О чём спор, господа ?

[Dimka]

О чём спор, господа ?

npak поднял любопытный вопрос о критериях выбора языка.

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

Фактически, пробуют новое только новички, которые ещё не "застряли" на чём-то.

[Алексей++]

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

[Dimka]

Алексей1153++, это ты проинтерпретировал под себя старый принцип "лучшее - враг хорошего" или, по пословице, "лучше синица в руках, чем журавль в небе".

Лично я в последнее время с новыми средствами знакомлюсь менее охотно по другой причине. Я сознаю, что пишу и проектирую хуже, чем мог бы. И понимаю, что новые языки и технологии это не исправляют. Поэтому я предпочитаю тратить время на совершенствование своих знаний и способностей, а не на освоение на практике чужих разработок. Хотя с идеями знакомлюсь охотно. Хочется создавать хорошо, а не потреблять "красивые фенечки". Как кто-то приводил высказывание безвестного подполковника: "В начале научитесь в сортире ссать, не промахиваясь, а потом уже будем высокие технологии осваивать."

[RXL]

dimka, что верно то верно.

И все же Java видится мне перегруженной. А пробовал года три назад браться за ее изучение и меня отпугнула сложность не самого языка (в нем то как раз не так много нового и правила его логичные), а "стандартных библиотек". К примеру, меня тогда интересовали аплеты: чтобы сделать обработчик GUI-события нужно наварачивать какие-то адептеры и прочую хрень. Т.е. для простых действий нужно долго возится со справочниками - крайне непродуктивно.

[Dimka]

чтобы сделать обработчик GUI-события нужно наварачивать какие-то адептеры и прочую хрень.

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

Хотя согласен, что изучение этого подхода, да и вообще концепций любой стандартной библиотеки любого языка требует наличия адекватной книжки-справочника.

И, соответственно, возникает необходимости читать эту нередко очень объёмную кокнижку, что сразу угнетает.

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

[RXL]

dimka, золотые слова (последнее)

Я тяготею к языкам со слабой типизацией. Человеческие интерфейсы, в основном, связаны с текстом, а сильно типизированные языки только усложняют работу с ним. Работа с бинарными данными в языках со слабой типизацией не сложнее, чем в языках типизированных, а зато удобнее.

[Dimka]

RXL, полностью согласен (с последним)

[sss]

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

[Алексей++]

Димка, так я ж согласное Знакомиться - всегда пожалуйста. Совершенствовать старое - тоже

[Dimka]

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

Да, а зачем о них задумываться при написании пользовательских формочек? Вот если речь идёт о каком-нибудь драйвере, обслуживании какой-нибудь быстро работающей железяки, написании конвертора или архиватора, 3D-графике - там, наверно, это надо.

P.S. Давеча прочитал про нетипизированное ООП в Perl и пришёл в ужас от синтаксического подхода к этому делу. Тогда уж лучше Lua или ECMAScript.

[Dimka]

Отделил последние сообщения о деталях Perl и ECMSScript в отдельную тему

[АлексейК]

Динамический полиморфизм позволяет сделать следующее:

class B
{
};

class D : public B
{
};

class C : public B
{
};

B* obj[2];
D* d = new D;
C* c = new C;
obj[0] = d;
obj[1] = c;

А как подобное сделать с помощью статического полиморфизма?

[Алексей++]

АлексейК, а где тут полиморфизм вообще ? Тут тупо наследование

[Dimka]

АлексейК, в указанном примере происходит уменьшение информации о типе объектов, помещаемых в массив. Доводя уменьшение информации о типе до предела, получим решение вида:

Код: (C)

int x = 5;
char *message = "Hello world!\n";
void *items[2];
items[0] = (void *)&x;
items[1] = (void *)message;

В случае непосредственного применения шаблонов (templates), уменьшения информации о типе не происходит, т.к. специализированный шаблон образует в программе новый тип.

Если и можно, то так или иначе в решении должна теряться информация о типах. Мне такие решения, которые не сводятся к "void *" или к наследованию, не известны.

Алексей1153++, учи матчасть

[АлексейК]

Прошу прощения, пример не полный. Если добавить виртуальные функции, то можно использовать один массив obj для вызова разных методов f():

Код:

class B
{
virtual void f(){};
};

class D : public B
{
virtual void f();
};

class C : public B
{
virtual void f();
};

void D::f()
{
}

void C::f()
{
}

main()
{
B* obj[2];
D* d = new D;
C* c = new C;
obj[0] = d;
obj[1] = c;
for(int i=0; i<2; i++)
  odj[i]->f();
}

Вопрос остается в силе.

[Вад]

А как подобное сделать с помощью статического полиморфизма?

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

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

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

Поэтому, в частности, можно использовать std::auto_ptr<Type1> и std::auto_ptr<Type2> единообразно (статически, а не в динамике). Или создавать std::vector<Type1> и std::vector<Type2> и делать для них, скажем std::sort или std::includes - порождать разные типы и оперировать с ними одинаково, пользуясь шаблонным интерфейсом.

То, чего ты хочешь, наверное, можно сделать через шаблоны и диспетчеризацию, но решение будет малость извращённым Например, вместо массива можно попробовать использовать специальный контейнер с диспетчеризацией по типу и перекрытым оператором []. Хотя я не уверен, что это будет работать. Потому что инструмент неподходящий.

Можешь ради любопытства посмотреть, как решаются сходные задачи, скажем, в ATL/WTL. Приходится использовать нешаблонный базовый класс с виртуальными методами, от которого наследуется шаблон, который диспетчеризирует вызовы своим специализациям-потомкам, требуя от них реализации дополнительных методов.

[Dimka]

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

Да, так тип Variant обычно описывают. Но в том-то и дело, что только наследование обеспечивает уменьшение информации о типе: все потомки сводятся к одному общему предку и через интерфейс предка неразличимы.

[lapulya]

Dimka, то что все потомки "сводятся" к одному (хотя не одному, но это детали) типу, это хорошо!, а не плохо. Все дело в проектировании. архитектура в идеале должна быть такова, что в качестве параметра функции и/или мембера класса должен передаваться объект только с необходимым интерфейсом и НИЧЕГО более (т.е. если клиент модуля/объекта предполагается работать только с интерфейсом IObject, то другая функциональность ему не нужна). Так что это не минус, а плюс. Да, есть случаи когда "невозможно" (или в 90% случаев просто у архитектора не хватает абстрактного мышления для того чтобы "разложения" объектов на интерфейсы) это сделать эффективно, тогда надо будет в обход строгой типизации "поднимать" тип до более высокого. Это плохо (медленно и потенциально не безопасно), но нет кода без изъяна. задача в том чтобы свести такие преобразования к минимуму (в идеале обойти или пересмотреть архитектуру).

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

При этом надо понимать, что статический "полиморфизм" никак не сможет заменить динамический полиморфизм, а вот обратный ворэрраунд без шаблонов возможен (в самом грубом приближении это ручная реализация каждого инстацирования, да отстой, НО можно и без потери безопасности, но с потерей гибкости).

[Dimka]

По-моему, ни хорошо и ни плохо, а просто так есть

Когда речь заходит об идеальной архитектуре, хорошо бы как-то обозначить критерии идеальности, что неминуемо поставит вопрос о целях проектирования...

Инкапсуляция мне не кажется самоцелью и абсолютным благом. Тут как с червями...

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

Когда проектировщик ставит инкапсуляцию самоцелью архитектуры, у него может даже получиться приближенное к идеалу решение, но ценой его будет заниженный предел по сложности организации проектируемой системы и большие общесистемные ограничения. Инкапсуляция, конечно, как раз и понижает сложность, чтобы всё уместилось в уме архитектора... Однако выйдет "червяк" - тормозная система, которая медленно и нудно гоняет из конца в конец разные данные, "синхронизируя" свои автономные и одинаково безликие части. Эти части друг другу не столько помогают в решении общесистемных задач, сколько конкурируют за ресурсы и заставляют друг друга обзаводиться разными приспособительными механизмами для взаимодействия между собой. Появляются всякие трёхэтажные wrapper'ы, неожиданные ошибки из-за дырявых абстракций и т.п. И выходит чудовище, которое разрастается, как плесень, и засасывает как болото. В конце концов выясняется, что ради повышения производительности и снижения стоимости сопровождения лучше всё выбросить и начать заново.

[lapulya]

Dimka, на тему архитектуры написана тьма книг, в их пересказе смысла не вижу.

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

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

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

Враппер есть хорошо, да это повышает накладные расходы, но при таком подходе каждый модуль изолирован от всех других и теоретически не зависим даже интерфейсно, более того враппер позволяет проводить тестирование каждого модуля в отдельности. Стандартный пример модуль шифрования для которого пишутся 2 затычки: одна "слева" подает на вход случайные или наперед известные данные и читает из выхода после чего сравнивает (если одинаковые, то все волшебно), вторая "справа" - получает зашифрованные данные с выхода и запихивает их на вход.

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

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

[Алексей++]

При этом надо понимать, что статический "полиморфизм" никак не сможет заменить динамический полиморфизм, а вот обратный ворэрраунд без шаблонов возможен (в самом грубом приближении это ручная реализация каждого инстацирования, да отстой, НО можно и без потери безопасности, но с потерей гибкости).

это на себе испытал )) Серьёзно программирую около 5 лет, но шаблонами начал пользоваться совсем недавно. Иногда, признаю, удобно их применять. Но старенькая VS6 иногда была против, ругалась на длинные внутренние имена и вообще зависала, отказываясь порой понимать, что от неё хотят. Студия №9 вроде адекватно себя ведёт (у  неё другие закидоны)