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

[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.: Прошу прощения за иронию, не смог удержаться.