Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
1) Мне нравится книжка Александреску (которая современное проектировнаие на C++). Но странною любовью нравится.
Собственно она позволяет понять насколько программист является грамотным инженером. Если книжка нравится и хочется немедленно всюду это дело применять -- то точно инженер плохой. Если уж с таким и сотрудничать, то очень внимательно контролировать чего он там напрограммировал. Точно ли не переусложнил?
2) Во-вторых, эта книжка мне нравится потому, что там очень хорошо и на примерах описано насколько плохо программировать таким образом
3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет
4) Ну и главное. В целом очень редко в программировании попадаются такие сложные задачи, что нужно то, что описано у Александреску скажем. Конечно теоретикам программирования на C++ реальные сложные практические случаи (скажем написаение графического редактора с каими-то хитрыми особенностями, или там системы распозанавания речи или ещё чего), а уж тем более какие-то простые и распространённые (скажем написание Web-интерфейса к какой-то БД) совсем уже не интересны. Потому что там уже трудно придумать что-то реально хорошее и нужное. А интересны либо какие-то извраты на почве синтаксиса, либо решение каких-то сверхсложных архитектурных задачь, в реальной жизни совсем не возникающих.
Но при этом не особо опытные инженеры этого всего не понимают и очень сильно переусложняют код.
Так что очень может быть, что стиот почитать вские умные книжки на эту тему, особенно про паттерны проектирования, но главная идея должна быть такая, что никогда не забывать точно ли это нужно для реально возникающих в твоей деятельности задач.
Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.
Просто такие программы писать труднее и требуется более высокая квалификация. Но, ИМХО, стремиться надо к этому, а не к созданию мегасупержутких наворотов.
Хотя для эрудиции эти все нароботки просмотреть конечно стоит
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, qqqqq, Вы писали:
Q>Книжка Александреску хороша, нет слов, да только не всегда все это все в пользу. Если програмируешь в основном один и очень хорошо в этом сам разобрался то конечно, да... А если работаешь в большой разнородной команде с текучкой где не все С++ программисты про итераторы слышали, то применение изощренных приемов из этой книги может заметно мешать. Только "избранные" смогут этот код понимать даже в приципе а поддерживать все "это" придется самому.
Когда слышу такие тезисы, у меня сразу возникает желание ответить следуещее:
Ну хорошо шаблонное программирование на полную силу не используем, т.к. могут придти программисты не знакомые с этим.
Так же не используем исключения, т.к. много неопытных программистов или программистов старой закалки с ними тоже не в ладах.
Ещё не используем контейнеры и алгоритмы стандартной библиотеки, т.к. многие так её и не освоили или вообще считают ересью.
Ни о каком boost и loki речи вообще не идёт.
Не используем паттерны проектирования и сложную архитектуру, т.к. могут придти программисты не разбирающиеся в этом.
Ну хорошо, назовите же уже те 20 функций из С, которые можно использовать в проекте! (больше 20 нельзя, вдруг у программиста будет плохая память)
Т.е. ты предлагаешь взять пересечение множеств умений всех программистов, которые работают и могут работать в будущем над проектом.
Существуют более прогрессивные методы управления процессом разработки, которые позволяют использовать не пересечение, а объединение возможностей программистов. think about it.
Q>Если поручат исправить простую ошибку менее квалифицированному кадру то он запросто там таких дров наломает, что все равно потом к тебе прибегут за помощью, когда гром грянет.
Ну и при чём тут шаблонное проектирование???
Если "менее квалифицированный кадр" будет работать один, то он где угодно сможет дров наломать.
Вообще это любого языка касается, но с++ особенно. Если менеджер посадил "менее квалифицированный кадр" писать код на с++, то чего он собственно ожидает?
Q>Но если тайная цель все под себя подмять в такой разнородной команаде то да, надо напихать в программу побольше патернов, темплейтов из этой и других подобных книг, замешать с STL, Loki, boost и АСЕ, и еще написать описание соответствено — цены тебе не будет. Видел я и проекты написанные на "обычном" C++ и исключительно advanced код, так вот те простые чаще были более удачные.
Здравствуйте, Erop, Вы писали:
E>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.
И в большинстве случаев лучше на Java, а не на C++.
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень . А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Вначале так сказать микро-уровень — это сам язык и "правильное" его использование. Тут я считаю вот это классикой:
Erop, дело в том, что Александреску подходит к проектированию как разработчик библиотеки общего назначения, которая будет потом использоваться в реальном прикладном коде, а ты мыслишь сразу категориями прикладного кода.
А у этих двух подходов принципиально разные задачи. У библиотечного — дать нечто максимально гибкое, всеобемлющее и удобное, чтобы его можно было заюзать при создании своего прикладного кода, а у прикладного — решить конкретную узкую и обычно простую задачу максимально простым и ясным способом.
Грубо говоря, если тебе нужно нечто вроде for_each(v, v+size, mem_fun_ptr), то если у тебя нет под рукой STL — ты напишешь цикл и не будешь париться, а если под рукой есть STL — ты заюзаешь for_each. Но несмотря на все преимущества for_each, если у тебя нет STL, то ради одного for_each городить всю многофайловую инфраструктуру из iterator, algorithm, functional и т.д. несколько неумно. Но если оно уже есть — почему бы этим не воспользоваться?
Я к тому, что нельзя с мерками прикладного кода подходить к библиотечному коду. А Александреску выступает именно как разработчик библиотек, и ничего страшного не произойдет, если ты, помимо STL, подключишь Loki, потому что пользоваться ею, насколько я понимаю — не сложнее, чем STL. А вся александресковская сложность — под капотом, ты ее и не увидишь и дела с ней иметь не будешь. Укажешь в параметрах типа, что именно тебе надо — и вперед.
А то, что ты пишешь про прикладной код — это все правильно и я с этим полностью согласен.
Здравствуйте, Erop, Вы писали:
КЛ>>6) Шаблон Visitor (к своему сожалению юзаю в 1ом месте, а ты? Пременимость — пр. пункт) E>Почему к сожалению и о чём именно ты сожалеешь? О том, что используешь или о том, что используешь один раз? E>Мне известно о четырёх серъёзных попытках использовать этот шаблон. Все четыре провалились. То есть потом код был всё-таки переписан, без визитора и стал проще, лучше, понятнее и всё такое.
Вот здесь присоединяюсь.
На мой взгляд, этот паттерн — один из самых неудачных.
В нашем проекте он используется в паре мест — эта пара если не возглавляет список самых противных мест проекта, то в первой десятке держится уверенно.
Самая большая проблема этого паттерна — абсолютно нечитабельный код, получающийся в результате.
Т.е. доходит до того, что там, скажем, появится запрос на что-нть сделать, ты сидишь, два дня разбираешься, что вся эта гора кода делает и куда же тебе встроиться. Так вот проблема в том, что если через месяц придет на этот участок еще одна задача — тебе опять потребуется потратить 2 дня, потому что запомнить это невозможно — все выглядит абсолютно одинаково, и с первого двухчасового взгляда совершенно непонятно, как же все это работает — потому что код, который делает что-то реально, представляет собой указатель на что-то, что принадлежит указателю на что-то другое, и аргументами ко всему этому идут указатели на третье и четвертое, и проследить через цепочки вызовов, откуда же все эти указатели пришли и чему они реально соответствуют — мозги вскипят. А когда эти указатели начнут совокупляться в разных сочетаниях, при этом заходя то в дверь, то в окно....
А вторая проблема — это ригидность структуры (но это вообще беда большинства паттернов).
Суть в том, что паттерн призван решить задачу минимумом кода, так? Т.е. понятно, что нужную структуру взаимоотношений классовв можно задизайнить десятком различных способов, и выбор в пользу того или иного дизайна определяется в том числе и тем, насколько он позволяет вносить изменения в дальнейшем. Так вот паттерны в основном задают чрезвычайно жесткую структуру (особенно паттерны поведения, типа визитора), ориентированную на какой-то один предполагаемый вид изменений, при этом все остальные превращаются в ад для программиста.
Я прошел через это в качестве "объекта бесчеловечных опытов" несколько раз. Конкретная подсистема, о которой я поведу речь для примера, призвана древообразно выполнять некие операции над определенным множеством объектов (операции порождают множества примерно таких же объектов, к ним могут быть применены другие операции, и т.д, дерево операций задает пользователь), а на выходе получается опять плоский список объектов (т.е. промежуточная структура обработки теряется). Так вот, организация классов, вся из себя красивая на первый взгляд, на самом деле заточена исключительно под то, чтобы добавление новой операции было легким делом. И эта задача худо-бедно выполнена, потому что (ну и остальные проблемы до кучи, из тех, что навскидку вспомнились):
Легко (действительно легко, этого не отнимешь) добавлять только операции того же типа, что уже есть. Добавление операции, работающей принципиально иначе, практически невозможно.
Операциям доступны какая-то небольшая информация об объектах. Попытаться достать дополнительную информацию — задача весьма нетривиальная.
Практически невозможно получать информацию о структуре, которая получилась, или получается, или об каком-то участке структуры (а это бывает необходимо для реализации нетривиальных операций).
Невозможно встроиться в существующий процесс обработки объектов (т.е. там, где есть необходимая информация, мы ничего не можем делать, а где можем делать — там этой информации уже нет)
Невозможно встроиться в какое-то конкретное место структуры, чтобы реализовать там дополнительную потребовавшуюся логику.
В результате, поскольку задачи должны выполняться, человек, на которого свалилось такое счастье, непрерывно матерясь, обвязывает код какими-то дополнительными списками, хэшами, чтобы по ходу сложить туда необходимую информацию, а в самом конце обработки (только там у нас есть результат), анализируя то, что получилось, с тем, что сохранено в его дополнительных нычках, производит необходимые действия. Причем эти действия иногда должны вернуть все эту филармонию к какому-то конкретному месту дерева и сказать пользователю, что вот здесь (т.е. в одной конкретной из заданных им оперций) раньше было так можно, а теперь нельзя, потому что законы поменялись.
КЛ>>7) Мультиметоды (не юзаю, а ты? Пр. — низкая(ИМХО)) E>Не использую и не верю, что может пригодиться
Да нет, было у меня в какой-то научной задаче, но давно и я уже не помню деталей. Помню, что без них пришлось туго, код получился совершенно неудобоваримым, хоть и работал. Но я его сваял и забыл, ибо проект не предполагал развития.
В принципе, за 10 лет промышленного программерства — 1 раз
Все по канонической присказке о парашюте.
P.S. Когда я выше употреблял слово "невозможно", я имел в виду "невозможно без полного переписывания всей подсистемы" — а в реальном работающем проекте такое переписывание проктически нереально. В результате получается как в известной карикатуре про качели, когда вырезана середина дерева, а верхушка стоит на двух свежесоструганных подпорках — очень точная аналогия: здесь в качестве вырезанной середины выступает как раз ядро инфораструктуры классов, оказавшейся абсолютно бесполезным (вернее, мешающим) для решения текущей задачи, и в результате задача решается через приставление все большего количества костылей в разных местах инфраструктуры.
P.P.S. Хотя, с другой стороны, никто не мешает объявить самым модным новый метапаттерн "костыли" — тогда все будет в полном соответствии с ныне модной методологией разработки
Здравствуйте, Erop, Вы писали:
E>4) Ну и главное. В целом очень редко в программировании попадаются такие сложные задачи, что нужно то, что описано у Александреску скажем.
E>Мне известно о четырёх серъёзных попытках использовать этот шаблон. Все четыре провалились. То есть потом код был всё-таки переписан, без визитора и стал проще, лучше, понятнее и всё такое.
Догадываюсь почему, сам наступал на такие грабли
Дело в том что визитор довольно нетривиальный и крассивый паттерн. К тому же — с довольно редкими начальным условиями (небольшая иерархия классов, невозможность или сложность модификации классов в иерархии, необходимость частого добавления новых операций). Как правило тот кто читает книжку банды четырёх первый раз приходит в восторг от такого красивого и элегантного решения. Большинство паттернов он уже в каком-то виде применял, хоть и называл это как-то по-другому или вообще никак не называл — а этот — что-то новенькое. И тут же возникает соблазн вкрутить его куда-нибудь. Это куда-нибудь как правило ну очень отдалённо похоже на visitor. Но настоящему инженеру море по колено — и вот, получите визитора там где он ну совсем не нужен . Ну а потом другой инженер — который уже пробовал впихивать визитора куда не надо (или вообще никогда не читал банду четырёх) — с матом и песняками выкидывает визитора и впедаливает куда как более простое и эффективное решение. Ну а после этого пишет на RSDN поднимая вопрос о правомочности существования визитора как такового и паттернов вообще
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр.
ИМХО, "стратегии", "паттерны" так бешенно популярны, потому как осилить все мировые запасы информации на эту тему проще, чем одну главу у Кнута. Потом ходишь и слова разные такие умные говоришь, все уважают. А какой прок от Кнута? (шучу, разумеется).
Положа руку на сердце — ведь то, что описано в любой лит-ре по дизайну/паттернам — доступно пониманию ребёнка. Берём для сравнения какую-нибудь книгу по, например, ЦОС, сжатию данных — упс — без определённой подготовки — далеко не уедешь.
Я не против паттернов, но: теоретическое знание паттернов — это то, что дёшего приобретают, но норовят дорого продавать. Спекуляцией попахивает. Любой нормальный программист с опытом от 3-5 лет и больше знает кучу паттернов, даже если никогда не штудировал эту тему специально. Пролистать соотств. лит-ру и такому не мешает, но каких либо великие откровения мало-мальски опытные программисты там вряд ли смогут обнаружить. Просьба не ссылатся на отдельных дебилов которые это утверждение якобы опровергают фактом своего существования.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Аноним, Вы писали:
E>1) Мне нравится книжка Александреску (которая современное проектировнаие на C++). Но странною любовью нравится.
[порезана инструкция по применению книжки Александреску]
Александреску сам месяц тому назад писал в clcm что скажет "До свидания" любому кто на интервью начнет писать громадные классы вместо for из двух строчек для того что-бы показать как работает for_each.
В этом то и состоит опыт программирования, когда ты изучаешь STL ты вставляешь его везде где не попадя и он вызубрен наизусть. Но когда уже есть опыт работы с STL ты понимаешь что вот здесь лучше забыть про него вообще а использовать (нервным попрошу удалиться из зала) ААААА!!!! указатели не защищенные shared_ptr
Всему надо знать меру, хорошая еда получаеться при правильных пропорциях а не когда "всего много".
Здравствуйте, Chipsеt, Вы писали:
C>Здравствуйте, Erop, Вы писали:
E>>Здравствуйте, Аноним, Вы писали:
E>>1) Мне нравится книжка Александреску (которая современное проектировнаие на C++). Но странною любовью нравится.
C>[порезана инструкция по применению книжки Александреску]
C>Александреску сам месяц тому назад писал в clcm что скажет "До свидания" любому кто на интервью начнет писать громадные классы вместо for из двух строчек для того что-бы показать как работает for_each. C>В этом то и состоит опыт программирования, когда ты изучаешь STL ты вставляешь его везде где не попадя и он вызубрен наизусть. Но когда уже есть опыт работы с STL ты понимаешь что вот здесь лучше забыть про него вообще а использовать (нервным попрошу удалиться из зала) ААААА!!!! указатели не защищенные shared_ptr C>Всему надо знать меру, хорошая еда получаеться при правильных пропорциях а не когда "всего много".
Да, но читать-то и знать всё это надо.
Энание и опыт не придёт никак иначе, кроме как через использование.
Вначале я не знал про for_each. Потом я знал про for_each, но не умел его применять. Потом я научился его применять и начал юзать везде где только можно и нельзя. Потом я понял, что это сакс и понял какие у него проблемы.
Зато теперь я знаю его вдоль и поперёк, я знаю, где его можно применить, а где нельзя. Я понимаю, зачем появился BOOST_FOREACH и т.д.
Может менеджеру или другому программисту конечно и не нравиться, что в промышленном коде появились for_each там, где не надо. Но пусть в конце концов отрефакторят или я сам это сделаю рано или поздно.
А есть программисты, которые сразу считают for_each — сакс, я его ни разу не применял, но всё равно это сакс.
Всё это перекликается ещё с такой мыслью, что все эти библиотеки, паттерны и приёмы — это готовые решения типовых проблем. И если программист ещё не сталкнулся с этой проблемой, или скорее сталкнулся, но для него ещё не стало очевидно, что это проблема, и что хорошо бы иметь готовое решение для неё, у этого программиста такие вещи, конечно, не будут вызывать ничего кроме недоумения. Конечно он будет говорить, что это ненужное усложнение.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Erop!
J>Erop, дело в том, что Александреску подходит к проектированию как разработчик библиотеки общего назначения, которая будет потом использоваться в реальном прикладном коде, а ты мыслишь сразу категориями прикладного кода. J>А у этих двух подходов принципиально разные задачи. У библиотечного — дать нечто максимально гибкое, всеобемлющее и удобное, чтобы его можно было заюзать при создании своего прикладного кода, а у прикладного — решить конкретную узкую и обычно простую задачу максимально простым и ясным способом.
[skip]
J>А то, что ты пишешь про прикладной код — это все правильно и я с этим полностью согласен.
Мысль, конечно правильная. Но. Мне лично достаточно жалко программиста (команду), который при работе с проектом порядка десятков/сотен тысяч строк кода на с++ не использует никакой инфрастуктуры/фреймворка для проекта, а прямо так и шпарит тысячи строк простого raw кода каждый день, который при возникновении любой проблемы в коде решает её здесь и сейчас самым простым способом... а завтра опять решает её в другом месте, а послезавтра опять решает её в другом месте. А потом в один прекрасный день встаёт необходимость чуть-чуть изменить решение этой проблемы....
Что я хочу сказать. При создании достаточно крупного проекта рано или поздно всегда встаёт вопрос о создании некой инфрастуктуры или, если хотите, библиотеки для проекта. А к ней уже применимы те же правила, что и к обычной библиотеке. Ну возможно некоторые упрощения есть. типа того, что можно только один компилятор поддерживать, и максимальную общность не обеспечивать.
И эту библиотеку тоже придётся поддерживать вместе с проектом. Т.ч. дублирование не умесно. А в с++, к сожалению, только самые примитивные виды дублирования можно устранить с помощью обычных функций. Если можно с помощью функции, то я конечно не против такого простого решения. Но часто просто не получается с помощью функции. Часто только ОО-подходы могут устанить дублирование. А часто и ОО-подходам это не под силу, тогда как-раз шаблоны и приходят на помощь (заметьте речь идёт о прикладном проекте). А иногда и шаблонам не под силу устранить дублирование, ну уж тогда на помощь приходят всеми нами любимые макросы.
Здравствуйте, Erop, Вы писали:
E>Я вот не особо понимаю что же за преимущества у for_each? Мне for в данном конкретном случае и понятнее и приятнее и если не дай божи чего не работате, меня не утянет "под капот" откуда я может и не вынырну без помощи более опытного товарища
Ну не for_each, а accumulate, copy, merge и т.д. Ты же, надеюсь, не при помощи qsort сортируешь? И мапы вручную не пишешь?
Практически всегда лучше писать одну строчку, чем 3, и уж тем более чем 30.
J>>Я к тому, что нельзя с мерками прикладного кода подходить к библиотечному коду. А Александреску выступает именно как разработчик библиотек, и ничего страшного не произойдет, если ты, помимо STL, подключишь Loki, потому что пользоваться ею, насколько я понимаю — не сложнее, чем STL. А вся александресковская сложность — под капотом, ты ее и не увидишь и дела с ней иметь не будешь. Укажешь в параметрах типа, что именно тебе надо — и вперед.
E>Ну вот мне не известно удачных случаев применения библиотеки Loki. В сложном коде, в простом, в очень сложном. Короче в любом. E>Мало того, я сильно подозреваю, что их никто не сможет привести. E>Хотя мне известны попытки. Все в конце концов неудачные. Как на уровне использования Loki, так и на уровне использования идей А.
Ты знаешь, я тоже таких примеров не знаю, у меня на работе на убогом сановском компиляторе оно не скомпилируется ни в жисть, а домашние проекты в основном на уровне скриптов, чтобы по-быстрому облегчить какую-нть тягомотную операцию.
Но, скажем, smart_ptr — он и в Африке smart_ptr. И, допустим, boost::shared_ptr довольно неплох, если бы не тот факт, что он свой счетчик размещает через new/delete, и ты никак не можешь на это повлиять. А это, понятное дело, очень сильно сказывается на производительности. А если бы аллокатор был аргументом smart_ptr наряду с хранимым типом — не пришлось бы писать дубликаты, как здесь, например (там оно называется "special counted"). У Александреску, насколько я помню, тип хранения счетчика — это аргумент SmartPtr (если я правильно помню имя класса). Причем, если я опять же, правильно помню — там можно в качестве стратегии задать "пустую" стратегию, которая не делает абсолютно ничего — это та вещь, которой я часто пользуюсь в реальной жизни, проверяя код на наличие утечек, только я это реализую в виде счетчиков объектов интрузивно (в смысле, добавляю счетчик, прогоняю программу, смотрю, чему равен счетчик в конце, если не ноль — значит, есть утечка). А со SmartPtr и правильной стратегией это можно автоматизировать и вообще сделать зависимым от режима компиляции (в смысле, #ifdef _NDEBUG), когда в релизе он будет вести себя как голый указатель.
Но, повторяю, я не пробовал локи вживую вообще, хотя было бы, безусловно, интересно.
Ты вспомни вообще классические библиотеки типа RW, борландовской, когда все стратегии по сути кодировались в имени класса, т.е. если (далее примеры про RWTools) в названии было Ptr, то хранились указатели, а если Val — то сами объекты. При этом, например, те, которые Ptr, в случае RW не удаляли все за собой (как могло бы показаться из названия), а борландовские, насколько я помню — удаляли. И, кстати, совершенно непонятно, чем же RWTPtrXXX<T> принципиально отличался от RWTValXXX<T*>. А если Isv — то это означало, что мы храним нечто интрузивное (только вот эту интрузивность ты по-человечески сделать не мог — хранимый тип обязательно должен был быть наследником соответствующего класса этой же библиотеки).
И что, это, ты считаешь, лучше? Когда у тебя есть несколько вариантов поведения одного и того же — родить соответствующее количество классов, закодировав варианты в названии? Я думаю, ты сам понимаешь, что это легко приводит к комбинаторному взрыву. Ведь в схеме с шаблонными стратегиями ты можешь написать какую-нибудь свою новую стратегию, которая будет делать именно то, что нужно тебе (например, удалять все элементы в деструкторе; или в конкретный момент посмотреть вокруг, что там есть, решить, что все плохо, и сдампить корку, чтобы ее можно было поисследовать дебаггером; или сделать на базе этого какой-нть memory leak detector, которого, например, очень не хватает в FireFox...)
J>>А то, что ты пишешь про прикладной код — это все правильно и я с этим полностью согласен. E>Ну я пишу простую вещь. Что не придумали ещё задач, которые столь сложны, что их решать проще с помощью Loki, чем без её помощи E>Вернее задачи может и придумали, но жизнь их пока не просит разрешить
SmartPtr — достойная задача? Имхо, почти на каждом шагу. SmallObjectAllocator? (Не помню, правда, совместим ли он с STL, если да, было бы вообще здорово — можно было бы рожать всякие std::map<int, double>, не особо боясь за эффективность.)
E>Мне не нравится парадигма "сделать так сложно, как только можно". E>Мне нравится парадигма "сделать так просто, как только можно".
Сам Александреску придерживается того же мнения http://rsdn.ru/Forum/Message.aspx?mid=1850161&only=1
E>При этом соображения о том, что "все сложности под капотом" не многое тут меняет. Потому что эти все сложности с нами. Мне и std::vector не нравится потому, что он заради довольно простой функциональности, рожает нереально много всяких сложных довесочков. И от них нельзя просто отказаться. E>Я бы, например, предпочёл, чтобы возможность использования алгоритмов подключалась в stl по явному требованию. А не была намертво в него вцементирована всегда.
так алгоритмы подключаются через #include <algorithm> явно
Это во-первых, а во-вторых, конкретно к вектору это никакого отношения не имеет, сам знаешь, алгоритмы работают на уровне итераторов (аналог указателей).
E>Потому что каждый раз, когда где-то, как правило в каком-то неудачном коде написанным невнимательным новичком, портится память, так я попадаю мордой под этот капот.И вынужден там ковыряться.
Аналогично и с "голыми" указателями. Но, по моему опыту, неправильное использование голых указателей отследить сложнее.
E>И при этом пользы-то никакой от наворотов я не получаю. Получаю гемор, поучаю догую компиляцию, получаю причудливую зависимость от версий компиляторов и библиотек и много чего ещё "хорошего".
Эту всю радость ты получишь абсолютно с любой библиотекой. Мне, по крайней мере, еще не попадались библиотеки, у которых никогда не было бы проблем при переходе с версии на версию компилятора (не говоря уже о смене компилятора с SunCC на GCC, скажем). И тем масштабнее проблемы, чем больше разница версий. А уж о том, как разные версии разных библиотек друг с другом уживаются — не сыпь соль на рану.
E>А вот реально хорошего от этой всей сложности получаю мало. Потому что все "выгоды", заради которых всё так непросто, они мне не нужны. И я не думаю, что потому, что я учавствую в разработке слилшком простых программ.
У меня эмпирический закон примерно такой: сложность кода определяется задачей, и только.
Если ты для решения сложной задачи используешь простые вещи — ты получишь огромный и сложный код.
Если ты используешь навороченные библиотеки — твой код будет простым (если это не так, либо ты неправильно эту библиотеку используешь, либо она неправильно спроектирована).
Грубо говоря, можно подключить libjpeg, а можно написать кодек самостоятельно прямо в production коде.
Суммарная сложность останется примерно той же.
Отсюда простая мораль: использование [правильно спроектированных] сложных вещей должно быть простым.
Чтобы в случае неправильной работы сразу было видно, в чем причина — в библиотеке или в твоем коде (STL в этом смысле, например, не идеал: одна возня с удалениями элементов контейнеров по итераторам чего стоит. Могли бы и предусмотреть сразу чего-нть на эту тему).
E>Я ещё раз призываю рассказать где же оно всё бывает нужно-то?
Ну уже сказал. В "Прикладных вопросах" был топик про реальное использование boost::mpl — посмотри еще там.
У меня лично сколь-нибудь нетривиальное использование шаблонов в основном сводится к traits, большего сановский компилятор просто не позволяет.
Подписываюсь. Читая книжку подумал "здорово, черт возьми". Потом подумал ещё, получилось "ну и на кой черт всё это надо?". Особенно мне нравится метапрограммирование с темплейтами: часок компилируем, отлаживать невозможно, ежели где запятую забыть — компилятор либо помрёт с internal error либо следующюю неделю можно посвятить чтению его ругани. Зато вычислим факториал во время компиляции — добрую тысячу тактов в рантайме наэкономим — может лучше константу на калькуляторе посчитать? Головоломки придумываем или всё же работаем?
Если бы я в университете каком работал и мне за такие вещи платили бы — может быть...
Выбирайте самое простое из всех возможных решений.
Хотя, такие взгляды лучше держать при себе: катить бочку на гуру — рискованное занятие, узколобые догматики-фетишисты на костре сжечь могут.
E>Потому что там уже трудно придумать что-то реально хорошее и нужное. А интересны либо какие-то извраты на почве синтаксиса, либо решение каких-то сверхсложных архитектурных задачь, в реальной жизни совсем не возникающих.
Угу. Никогда не слышал ни о чем мало-мальски полезном, в написании чего участвовали бы все эти гуру от языков. Так же как и гуру от архитектуры. Если так извращатся как они рекомендуют — до практически полезного результата в жизни не доберёшся.
K>Попробуй вначале разобраться с STL. Я Александреску читал, был в восторге. Однако на практике применить материал удаётся крайне редко. Так что можно особо не торопиться с современным программированием. Оно, как искуство каллиграфии, уходит в область, далёкую от практических задач.
Приколола фраза выделенная выше. Материал нужно применять только если это реально необходимо а не пытаться впихнуть его куда-нибудь только потому что это есть и выглядит круто и устрашающе.
Здравствуйте, Erop, Вы писали:
E>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog.
Это не Prolog. Это Lisp.
> Но совсем не раскрыл тему "зачем так извращаться?"
Ты не читал предисловие.
Imagine the following scenario. You come from a design meeting with a couple of printed diagrams, scribbled with your annotations. Okay, the event type passed between these objects is not char anymore; it's int. You change one line of code. The smart pointers to Widget are too slow; they should go unchecked. You change one line of code. The object factory needs to support the new Gadget class just added by another department. You change one line of code.
You have changed the design. Compile. Link. Done.
Well, there is something wrong with this scenario, isn't there? A much more likely scenario is this: You come from the meeting in a hurry because you have a pile of work to do. You fire a global search. You perform surgery on code. You add code. You introduce bugs. You remove the bugs . . . that's the way a programmer's job is, right? Although this book cannot possibly promise you the first scenario, it is nonetheless a resolute step in that direction. It tries to present C++ as a newly discovered language for software architects.
А вообще, книга описывает основные паттерны проектирования, которые нужно уже давно знать и использовать самому. Нельзя изучать паттерны по книге Александреску. Нужно прочитать Gang of Four и попробовать делать так как там написано. А потом, когда надоест писать горы однотипного кода и появиться желание как-то автоматизировать этот процесс, то тут приходят на помощь идеи Александреску.
Если ты не используешь паттерны. Александреску тебе ничего не даёт, а просто сотрясает воздух в пустую.
A>1) Кто-нибудь захочет создать еще один объект CMySingletonObject, и у него это получится.
Ну, эта-то проблема разрешима в пол-пинка Никто не мешает сделать конструкторы-деструкторы закрытыми. К основной идее это отношения не имеет. A>2) Проблемы инициализации и деинициализации здесь не разрешимы. (Мне долго не давал покоя один вопрос, почему Adobe Photoshop так долго стартует. Так ведь у них, наверное, всё инициализируется такими "синглтонами".)
Я так понимаю, ты имеешь в виду проблемы зависимостей между синглтонами? Тут сугубо моя сугубо личная ИМХА в том что эти зависимости надо всячески искоренять. Если два синглтона зависят от инициализации друг друга — пусть они не будут синглтонами, а просто будут агрегированы внутри одного синлтона. A>3) Это просто глобальный объект со всеми его прелестями.
Вот тут не понял В чём прелести-то? В видимости для линкера? Тоже элементарно устраняется — функция CMySingletonObject::Instace засовывается в cpp, в том же cpp пишется:
Ну и про photoshop — я так понял ты имеешь в виду что этот глобальный обьект может иметь "тяжёлый" конструктор? Так тоже вроде бы не проблема — если уж действительно конструктор тяжёлый — то никто не мешает сделать инициализацию по требованию. A>Вообще, надо иметь смелость сказать, что глобальные объекты эквивалентны синглтонам.
Беру на себя смелость Я тоже одно время очень любил писать по каждому поводу отдельный синглтон — а потом понял что в 90% случаев геморрой не стоит свеч.
Здравствуйте, Alex_Avr, Вы писали:
E>>Заменть реализацию STL обычно что-нибудь мешает. Так что реализация STL обычно навязывается целевой платформой, особенно если ты портишь библиотеку A_A>Для расширения кругозора — можно узнать причины, которые мешают заменить используемую реализацию STL на другую, кроме заточенности A_A>кода на особенности конкретной реализации и своих доработок ее напильником?
Примеры причин, которые я встречал
1) В портируемой библиотеке есть желание иметь общую с её клиентом c-шную кучу. Это приводит к тому, что нужно использовать тот c-runtime, который используется в клиентской коде. Ну а это приводит к зависимости по версиям всех компонент, в том числе и STL
2) Под OS Linux если вы пишете библиотеку или даже SB-шку, всем компонентам доступны все символы.
Это приводит к тому, что если в двух частях программы используются разные реализации STL, то всякие приватные шаблонные потроха начинают конкурировать по именам. Нарушается ODR собственно говоря. А так как нарушители шаблонные, то линкер это дело пропускает.
Так что какие-то случайные места проекта от сборки к сборке (или даже от загрузки к загрузке) начинают сбоить из-за того, что в данном конкретном месте взялась не та версия потрохов.
Поддерживать такое -- просто мечта поэта. Без работы, во всяком случае, точно не останешься
3) При попытках использовать в сложных проектах неродные для компилятора реализации STL неоднократно наталкивался на проблемы компиляторов или линкеров. Всё-таки STL довольно тяжёлая хреновина, а если и проект нелёгкий, то компилер может начать чихать. Чихает обычно как-то небанально ((
E>>2) У нас есть своя реализация шаблонной сортировки. Она без многих чудес, сделана из какого-то популярного в CS алгоритма и довольно хорошо работает. A_A>Для вас реализация, отладка и тестирование своего алгоритма сортировки была оправдана, а для кого-то это не так.
Я понимаю. Если мне надо будет сделать какой-то не очень большой проект, и ничего лучше STL под рукой не окажется -- будем писать на STL. Но этонифига не оправдывает STL идеологически Всё равно он переусложнён, на мой скромный взгляд
A_A>...обычных массивов в стиле C. Если вам все это не нужно, и есть ваша собственная библиотека — так зачем вам STL?
Ну так я и говорю, что мы его стараемся избегать
A_A>STL такая, какая есть, потому что нацелена на универсальность использования, а более общее и универсальное решение A_A>всегда сложнее более частного решения.
Ну так я про то и спорю, что идеология, что если есть возможность вместо конкретного средства забацать (или использовать) "универсальный всемогутер", то надо делать всемогутер. А мне кажется, что нужно ровно наоборот. Чем меньше всемогутеров и чем менее они универсальны, тем обычно это ближе к оптимальному инженерному решению, а идея многих неопытных программистов и даже, как это не печально, многих преподавателей, ровно противоположенная
A_A>всё это счастье добавляет хорошо продуманная архитектура проекта. A_A>Ну это ты уже утрируешь. Выше я писал о том, для чего нужны итераторы.
Да ничего я не утрирую. Мне кажется, что редко очень бывает нужно заменять массив на список при "добавлении функциональности", если проект был хоть чуть чуть спроектирован нормально.
Мало того, ИМХО, можно хоть упраграммировать всё итераторами, но при дурной архитектуре, замена типа контейнера бесследно ен проходит, а при нормально йтакой нужды и не возникает
E>>А многим неопытным инженерам кажется, что намного важнее применить какой-то сверхумный и сверхгибкий указатель, да ещё проследить, чтобы не было goto A_A>Понимание многих вещей приходит только с опытом.
Ну можно считать, что я пытаюсь им делиться, но некоторые с ним не согласны
A_A>Так и из Стандарта они никуда не денутся. Единственный выход — не использовать STL вообще A_A>и писать свои библиотеки или использовать другие подходящие для ваших требований, тот же Roguе Wave, A_A>например.
+1
A_A>Можно предложить свои классы в качестве дополнения в следующий Стандарт С++
Ну лично я вот не верю, что поможет. Всем слишком нравится А.
E>>Ну boost очень разнороден. Содержит и дельные вещи, но навороты ИМХО всё время не по делу. A_A>И не для любого компилятора.
++1
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
КЛ>>2) Реализация шаблона Singleton (В какой-то степени, а ты? Применимость — почти каждый юзает в том или ином виде) E>Не использую. Мало того, считаю, что самая хорошая реализация синглетона -- это что-то типа: E>
E>class CMySingletonObject {
E> // тут что-то такое
E>};
E>extern CMySingletonObject MySingletonObject;
E>
1) Кто-нибудь захочет создать еще один объект CMySingletonObject, и у него это получится.
2) Проблемы инициализации и деинициализации здесь не разрешимы. (Мне долго не давал покоя один вопрос, почему Adobe Photoshop так долго стартует. Так ведь у них, наверное, всё инициализируется такими "синглтонами".)
3) Это просто глобальный объект со всеми его прелестями.
Вообще, надо иметь смелость сказать, что глобальные объекты эквивалентны синглтонам.
Здравствуйте, Константин Л., Вы писали:
КЛ>Он это сказал аж в 2002 году. Для кого-то это не ново, для кого-то ново.
На самом деле книга вышла в начале 2001 года. Наверное, пять лет назад она была чем-то новым и интересным. А на мой вкус, если нужна книжка о шаблонах, то сейчас есть замечательная "C++ Templates: The Complete Guide", про паттерны тоже надо читать не Александреску. А вот если возникла идея реализовать свой велосипед аналогичный какому-нибудь из Loki-велосипедов, то в книжку эту можно и заглянуть, чтобы посмотреть описание одного из путей реализации и граблей с ним связанных.
Здравствуйте, igna, Вы писали:
I>Ну вот те на. А я то думал, что иронию данного в форуме по C++ совета программировать на Java не заметить будет трудно.
Ну иногда у людей бывает ценность "написать программу которая делает то-то и то-то", а иногда даже и ценность "сделать то-то и то-то, а для этого написать программу такую и растакую. И часто так бывает, что для написания программ удобно использовать C++
А бывает, что люди пишут что угодно и как угодно (например максимально сложно), лишь бы на C++. Вторые наверняка оценили твою иронию
I>Хорошо, открытым текстом: Ощущающим непреодолимую потребность в опрощении вряд ли стоит продолжать программировать на C++.
Не менее открытым текстом: Людям, которые испытывают потребность в самоутверждении путём написания мегакрутых и сложных версий устаревшей и слишкомп понятной программы "Hello World" стоит сменить C++ на что-нибудь менее простое и более непонятное.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Берёте Stingray (RogueWave) продукты (C++ библиотеки). Документация восторженнo рассказывает вам о том, какой паттерн где задействован (а мне лично не это в первую очередь интересно, мне бы про то, как пользоватся). А библиотеки — бажные, хуже некуда. Лезть же в этот паттерн-спагетти — себе дороже.
Мой жизненный опыт говорит о том, что сложности придумывают в двух случаях:
1) Не умеют работать
2) Раздувают объём работ
Ну и как дополнительный вариант — комбинация этих двух.
Много вы от майкрософта про UML, паттерны и проч. слышите (про паттерны заговорили только в посл. время)? Код у них как правило "С с классами". Но кой-какие практические результаты налицо. А покажите мне плоды трудов проповедников сложности и те огромные проекты, с которыми они справлись благодаря своим теориям. Они все аппелируют к "большим проектам" — где их большие проекты?
Я не говорю что теже паттерны — плохо, в конце концов самой нужной половиной из описанных в лит-ре все и так всю жизнь пользуются, только до жуткой на них моды не знали, что это так называется.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, qqqqq, Вы писали:
[skiped...] R>Не используем паттерны проектирования и сложную архитектуру, т.к. могут придти программисты не разбирающиеся в этом.
[skiped...]
Конечно не используем "сложную архитектуру" но применяем патерны. Задача патернов — упростить архитектуру а не наоборот.
хорошая архитектура == простая архитектура, самая простая которая решает поставленные задачи.
Тут уже многократно выскзывалась мысль, что квалификация инженера не сопсобность разбираться в сложной архитектуре , а не создавать ее.
Left2 wrote: > То есть, она не понимает не-IDispatch унаследованных интерфейсов или ей > не нравится когда в методы передаются не Variant-совместимые типы? А то > ведь в ActiveX море интерфейсов которые не унаследованы от IDispatch...
Ей не нравятся некоторые advanced-конструкции IDL, связаные с
custom-марашаллингом.
При желании можно дописать ее генератор кода, но мне было проще самому
написать обертки некоторых классов.
> Вообще интересен совет от профессионала который этой библиотекой > пользовался — стоит ли вообще тратить время на то чтобы с ней > разбираться или преимущества её перед ATL не стоят свеч?
У меня достаточно сложная модель объектов в приложении, так что мне
очень удобно использовать Comet.
И еще по мелочам: есть очень удобный класс для работы с реестром,
STL-compatible bstr_t, "правильная" обертка для VARIANT'а и т.п.
Comet можно использовать совместно с ATL. Например, с помощью ATL
реализуем ActiveXовые интерфейсы, а Comet используем для прикладных
интерфейсов. Причем в одном coclass'е.
Left2 wrote: > C>А вот удобнее — вряд ли. Через пару недель использования Comet'овских > C>стабов при необходимости использовать ATL тянет перейти нафиг на C# > А недостатки у этой вундерваффе (Comet) есть?
Есть. Оно понимает только Automation-compatible интерфейсы, в результате
обертки для IStream/IStorage пришлось писать самому по образу и подобию
Comet.
Erop wrote: > Но вот от списков типов и от Loki я бы отказался однозначно во всех > известных мне проектах.
Тем не менее, иногда оно полезно:
class ODAS2Frame :
public coclass<ODAS2::ODAS2Frame, thread_model::Apartment,
ILocalCPPObjectImpl<ODAS2Frame>,
ISigCastImpl<ODAS2Frame> >,
...
{
...
};
ODAS2::ODAS2Frame — это список типов, а coclass — метапрограмма, которая
добавляет этот список типов и два последних интерфейса (ISigCast,
ILocalCPPObject) в список базовых объектов.
Так что не нужно писать карты интерфейсов как в ATL/MFC. А благодаря
CRTP можно _нормально_ использовать наследование и COM-объекты.
Здравствуйте, mukos, Вы писали:
M>(вчера читал у Майерса чьето высказывание (может его) "Нужно писать просто насколько M>возможно ,но не более"(хотя вроде это был Шекспир))
Здравствуйте, alexeiz, Вы писали:
A> Соответственно я их характеризую как действительно полезные и попадающиеся в реальности.
Абсолютно согласен. Паттерны вообще это обобщение реального опыта проектирования приложений. Т.е. паттерны это не некие синтетические конструкции, а некие часто встречающиеся и возникающие вполне естественным путем(в результате грамотного или неграмотного проектирования) идиомы проектирования.
И естественно, как и любой другой опыт со стороны применение паттернов не всегда дает хороший результат. Любой инструмент и идиому нужно выбирать и применять с умом. Понимание и знание паттернов иногда позволяет выбрать подходящее архитектурное решение, но это не значит что применять их нужно направо и налево. Кстати зачастую паттерны применяются неосознанно и всплывают в дизайне людей совершенно незнакомых с таким понятием как таковым. Да и вообще паттерн он на то и шаблон/образец, теоретически можно обобщить в паттерн самый разный дизайн. Проблема только в том, что зачастую такой паттерн будет кривым и некрасивым(как и дизайн ). А вот паттерны вроде паттернов GoF это попытка обобщить именно положительный опыт.
Вообще архитектура и дизайн это далеко не только паттерны, это сложная и практически всеобъемлющая тема. Об этом можно говорить и спорить практически бесконечно. Есть люди которые прекрасно живут, и реализуют проекты и без паттернов, да и вообще практически без архитектуры(т.е. без осознанной архитектуры). Есть люди которые занимаются проектированием в первую очередь(не говоря уже о такой загадочной профессии как архитектор). В конце концов есть подходы вроде XP(которые мне лично наиболее симпатичны в данный момент времени). И конечно так сразу не скажешь кто здесь абсолютно прав, а кто совершенно нет.
A>Я бы сказал, что всё кроме мультиметодов из этого списка является действительно полезным и часто применяемым.
Нельзя не согласиться. Не говоря уже о более приземленных вещах, которые очень хорошо описанны в книге.
E>>А вообще интересно, почему тебе кажется, что скорее LISP, а не Prolog? A>Typelists, head, tail, рекурсивные обработки списков — это Lisp чистой воды.
А вот здесь не совсем согласен. Списки, рекурсивная обработка, head, tail свойственны и для Пролога. Да и мне лично показалось, что реализация всего этого в Loki действительно больше напоминает Пролог, чем Lisp(на момент первого прочтения книги я был знаком и с тем, и с другим).
Почему?
1. Если-бы это был Lisp чистой воды, то вместо head и tail были бы car и cdr.
2. Параметры шаблонов и "переменные" пролога роднит общепринятая практика писать первые заглавными буквами(вторые иначе просто и нельзя записать).
3. Паттерн-мэтчинг(которого кстати нет в Лиспе) Пролога удивительным образом по духу напоминает специализацию в C++.
Но на самом деле конечно ни Prolog, ни Lisp здесь совершенно не причем(тем более что Александреску скорее всего имеет поверхностное знакомство и с тем, и с другим). Typelists из Loki это скорее результат "синтеза" знаний о нескольких функциональных языках, в которых списки являются основной структурой данных, в первую очередь ML и Haskell(оба языка кстати вскользь упоминаются в книге). Конечно речь идет о чисто внешних деталях реализации, так сказать эстетике, поскольку насколько мне известно Александреску вроде бы не пионер в данном направлении программирования на C++. Первые опыты на эту тему скорее всего были "вдохновленны" именно Лиспом.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Аноним, Вы писали:
А>>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
E>1) Мне нравится книжка Александреску (которая современное проектировнаие на C++). Но странною любовью нравится.
E>...
Зачастую есть такая тема. Иногда себя на этом ловлю. Но.
1. Александреску, по-моему, этого не делает, но Саттер вначале каждой книги пишет, что голова должна быть превыше всего, что всё о чём он пишет не должно заменять здравого смысла. Человек-разумный должен это понимать.
2. У каждого языка/инструмента/технологии есть своя область применимости. Это касается и того, о чём пишет Александреску, и языка с++ как такового, и Java, и ООП и БД. Вообще всего.
3. Чем шыре у специалиста кругозор, тем он может выбрать более вдекватное решение для конкретной задачи.
Т.ч. я считаю, что такой "наезд" на Современное проектирование не обоснован. Эти же мысли можно применить ко всему, он тут ни при чём.
Например, недавно мне надо было реализовать около 50 различных поведений (классов). Причём, если подумать, то каждый класс тз этого множество достаточно чётко разделяется на несколько аспектов. И существует по несколько реализаций каждого аспекта. Когда все эти реализации каждого аспекта перемножаются друг на друга и получается более 50 вариантов поведения. Как предлагаешь это реализовывать? При этом каждый аспект достаточно часто меняется независимо от других.
Или например фабрики. Недавно видел пару сотен строк кода для реализации обычной абструктной фабрики.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Некоторые виды дублирования нельзя устранить ни какими способами, кроме advanced-templates (не считая таких отстойных вещей как макросы и void*).
R>>Моё обоснование использования advanced-templates в двух указанных выше предпосылках.
R>>По мимо очень большой скорости правки кода, тебе так же понадобиться идеальная внимательность, т.к. при исправлении какого-либо аспекта в паре десятков мест надо везде сделать правильно.
R>>Идеальной внимательностью я кстати тоже не обладаю, поэтому не люблю, когда мне приходится "поправлять" десятки "почти похожих мест" в проекте.
E>Прекрасно! E>Расскажи как тебе помогают в твоих многочисленных бедах мультиметоды и for_each
E>Главная проблема с шаблонами, ИМХО, такая, что часто при редактировании нетривильного шаблона очень трудно предсказать все последствия.
Одно из свойств advanced-templates в том, что "уж если вся эта бойда скомпилировалась, значит она работает так, как надо". Я в этом сам неоднократно убеждался на примере boost::bind.
Ты фактически описываешь то, что ты хочешь получить декларативно. Да, иногда, вызывает проблемы объяснить компилятору, что же именно ты хочешь получить, что бы он понял. Но уже если объяснил, то это работает. Т.к. ты не описывал, как ты хочешь это получить. А ошибки бывают обычно именно в этом.
Т.е. проблемы обычно присытствуют в компайл-тайм.
При использовании старых добрах ран-тайм средств всё проблемы просто переносятся соответственно в ран-тайм.
Выбирать каждому самому. Я лично предпочитаю проблемы в компайл-тайм.
Приведу пример. Недавно надо было поправить ядро библиотеки. Библиотека была на так сказать advanced-templates. Написана была достаточно грамотно. Так вот после исправления некоторой части кода, попытался скомпилировать. Не скомпилировалось. Многое сломалось. Где-то static_assert'ы ругаются, где-то просто компилятор. При использовании явных интерфейсов, всё бы замечательно скомпилировалось — ошибки пришлось искать в ран-тайме. Вот в частности за такие вещи мне нравятся advanced-templates и идеи А.
Книжка Александреску хороша, нет слов, да только не всегда все это все в пользу. Если програмируешь в основном один и очень хорошо в этом сам разобрался то конечно, да... А если работаешь в большой разнородной команде с текучкой где не все С++ программисты про итераторы слышали, то применение изощренных приемов из этой книги может заметно мешать. Только "избранные" смогут этот код понимать даже в приципе а поддерживать все "это" придется самому. Если поручат исправить простую ошибку менее квалифицированному кадру то он запросто там таких дров наломает, что все равно потом к тебе прибегут за помощью, когда гром грянет. Но если тайная цель все под себя подмять в такой разнородной команаде то да, надо напихать в программу побольше патернов, темплейтов из этой и других подобных книг, замешать с STL, Loki, boost и АСЕ, и еще написать описание соответствено — цены тебе не будет. Видел я и проекты написанные на "обычном" C++ и исключительно advanced код, так вот те простые чаще были более удачные.
Другие отностительно новые книжки по "продвинутому" C++ — Exceptional C+, More Exceptional C+, Effective STL, C++ Templates: The Complete Guide, и еще может пара книжек то ACE
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>"Навёрнутые" или не "навёрнутые" — это субъективное мнение. Мне сейчас это не кажется навёрнутым. Просто другая форма записи тем же самых вещей. Не вижу никакой принципиальной разницы между включением нескольких указателей на динамические интерфейсы или включением нескольких указателей на статические интерффейсы. Синтаксис немного другой. Да, у шаблонов синтаксис порядочно сложнее, с этим согласен. Вначале снепривычки было сложно, но сейчас практически одинаково.
E>У шаблонов есть много "преимуществ" E>1) Намного хуже, чем в случае интерфейсов заданы правила использования. В результате грамотный шаблон написать труднее (больше надо всегопредусмотреть), и воспользоваться труднее (надо выбрать из большего числа мыслемыз альтернативных способов использования)
Ничто не мешает задать их так же явно. Например так:
//Класс TLog должен быть copy-constructable и иметь следующий интерфейс:struct TLog
{
void log(const std::string&);
int fff();
};
В следующей версии стандарта языка эту проблему возможно решат более элегантно.
Зато и возможностей больше. Гораздо больше. Причём принципиально новых. Вспомни хотя бы std::vector<>! Как ты его предлагаешь реализовывать без шаблонов? Или ты его не используешь?
E>2) Намного более сложный синтаксис и семантика. Вот, например, что тут написано: E>
E>template<typename TLog>
E>class Base {
E>protected
E> void exit( int );
E>};
E>template<typename TLog>
E>class MyExitProicessor : public Base<TLog> {
E>public:
E> void OnExit( TLog& log, int code )
E> {
E> LogExit( log, code ); // это какой-то метод MyExitProicessor, описанный ниже
E> exit( code );
E> }
E>};
E>
Имхо. Всё понятно. Кстати, лучше писать "this->LogExit()" и "this->exit()", тогда и понятнее будет.
E>3) Очень неудобные сообщения об ошибках в пользовательском коде.
В большинстве случаев точно такие же как и без шаблонов. Надо просто их внимательно прочитать, а не говорить сразу "ух ты #$%, я это даже читать не буду". Вот ещё здесь.
E>А вот реальные приимущества всех этих трюков Александреску они в чём?
Меньше дублирования. Лучше понятны намерения программиста. Аспекты лучше выделены, а не замешаны в один клубок. Но это всё достигается за счёт наличия более сложного (интеллектуального) кода.
Я так считаю: можно иметь или много "тупого" кода (я его называю "raw"), это когда много накопипастеных функций, или меньше кода, но более "интеллектуального".
Кстати, можно узнать про твоё отношение к исключениям. Ты их используешь в с++?
Здравствуйте, Константин Л., Вы писали:
КЛ>1) Обощенные функторы (не использую, а ты? Применимость — хз, но думаю средняя)
Не использую. КЛ>2) Реализация шаблона Singleton (В какой-то степени, а ты? Применимость — почти каждый юзает в том или ином виде)
Не использую. Мало того, считаю, что самая хорошая реализация синглетона -- это что-то типа:
class CMySingletonObject {
// тут что-то такое
};
extern CMySingletonObject MySingletonObject;
Иногда, но уже довольно редко, бывает и так, что в конструкторе синглетона инициализируют указатель этот единственный объект, и что-то такое проверяют assert'ами.
А делают это всё потому, что нужен
, который в каких-то случаях один, а в каких-то другой. Но я знаю всего один пример, когда так сделали не во зло, и то пример сомнительный. Так сказать на грани.
КЛ>3) Интеллектуальные указатели (юзаю, а ты? то же, что и предыдущий)
Использую, но не такие сложные, как у А. Но шаблонные
НО конкретно в умных указателях, ИМХО, А. нисего нового и при этом полезного не сказал.
КЛ>4) Фабрики объектов (не изаю, нет необходимости. А ты? Применимость — имхо средняя)
Фабрики объектов иногда у меня бывают, но не очень часто. при этом они всегда сделаны по месту. Шаблонных наворотов нету
У нас в конторе есть одна шаблонная фабрика. РАдикально более простая, чем у А. кстати. Вернее фабрика не шаблонная, шаблонный регистратор типа объекта.
КЛ>5) Шаблон Abstract Factory (см. пред. пункт)
Не использую. Хотя, наверное то, что есть у нас в конторе, ближе сюда
КЛ>6) Шаблон Visitor (к своему сожалению юзаю в 1ом месте, а ты? Пременимость — пр. пункт)
Почему к сожалению и о чём именно ты сожалеешь? О том, что используешь или о том, что используешь один раз?
Мне известно о четырёх серъёзных попытках использовать этот шаблон. Все четыре провалились. То есть потом код был всё-таки переписан, без визитора и стал проще, лучше, понятнее и всё такое.
КЛ>7) Мультиметоды (не юзаю, а ты? Пр. — низкая(ИМХО))
Не использую и не верю, что может пригодиться
КЛ>Кроме практической ценности эта книга имеет очень большую теоретическую ценность.
++++1
С этим я никогда и не спорил
Мало того, я считаю, что читать её полезно, чтобы научиться смотреить на вещи и таким образом, но при этом надо пнимать, что целесообразность такой красоты красоты ты сможешь оценить только приобретя изрядного опыта, ну и должно понимать, что применять это всё скорее всего не надо.
А так да, согласен
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Т.е. ты предлагаешь взять пересечение множеств умений всех программистов, которые работают и могут работать в будущем над проектом.
Этот подход тоже вполне имеет право на существование.
Чем менее квалифицированные программисты нужны, тем меньше риски проекта, потому что в любой момент ты можешь взять с улицы первого попавшегося и он вольется в команду за пару дней.
А если сидит квалифицированный перец, который мыслит исключительно рекурсивными шаблонами — то даже если ты построишь процесс разработки так, что все будет хорошо, пока этот программист в штате, что случится, когда он уйдет? Кто подхватит знамя? Аналогичного по скиллам ты быстро не найдешь, а проект все это время должен развиваться (банально должны оперативно фикситься баги), а не ждать, когда же придет очередная звезда с "шаблонным" мышлением.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
КЛ>>Не совсем. Добавление нового класса влечет за собой добавление новых методов void Visitor::Visit( SomeNewType& ); void SomeNewType::Accept( Visitor* ). КЛ>>При этом меняется только интерфейс Visitor'а. Новые операции появляются за счет создания наследников Visitor'а. Так что о не применимости этого паттерна к иерархии, которая изменяется( в большинстве же случаев она разрастается ) не совсем корректно. Как раз о ее применимости и пишет господин А. КЛ>>Кстати, она у меня скорее всего не изменится никогда.
E>Но, казалось бы, операция у тебя всего одна -- типа выбрали элемент. E>На кой тебе визитёр?
Захотелось сделать так. А насколько это оправданно?... Просто тогда мне показалось это более целесообразным. Может быть завтра я посмотрю на тот код и удивлюсь, зачем я так сделал.
Здравствуйте, alexeiz, Вы писали:
A>1) Кто-нибудь захочет создать еще один объект CMySingletonObject, и у него это получится.
Имхо, если кто-то захочет всё сломать, он это сделает. Я не встречался с такой проблемой, что кто-то создавал бездумно вторую копию объекта, уникального по своему смыслу. Всё-так программисты они вменяемые обычно, и нацелены на результат
ИМХО все попытки сделать так, чтобы нельзя было сдлеать вторую копию синглетона -- борьба с несуществующими проблемами.
Единственный контекст, когда я такую проблему встречал -- это приложение состоящее из несколькоих DLL, но вот тогда как раз все шаблонные решения начинают пробуксовывать
A>2) Проблемы инициализации и деинициализации здесь не разрешимы. (Мне долго не давал покоя один вопрос, почему Adobe Photoshop так долго стартует. Так ведь у них, наверное, всё инициализируется такими "синглтонами".)
ИМХО проблемы инициализации и деинициализации неразрешимы в осноывном в сознании авторов синглетонов
На мой взгляд лучше всего, когда НЕТ ЗАВИСИМОСТИ между статическими объектами ПО ПОРЯДКУ ИНИЦИАЛИЗАЦИИ.
Если этого почему-то совсем совсем никак не удаётся добиться, то можно поступить так.
Взять продумать в каком же порядке это всё должно инициализироваться, чтобы было счастье.
И в каком-то одном месте, ну типа в InitInstance или ещё где вызвать функции инициализации зависящих от порядка инициализации в нужном тебе порядке. При этом, когда следующий программист (или ты сам через полгода) захочет туда добавить вызов ещё одной инициализилки (или убрать) он сразу всё узнает и поправит. А не будет с полным охренением лазить по всем местам, где есть синглетоны и восстанавливать кто от кого как и зачем зависит.
Что касается фотошопа, кстати, то тоже всё интересно. Фотошоп грузит много всего. Я так понимаю, что грузить всё равно надо. Так что время идёт на доброе дело. Но вот то, что он сначала запускается, рисует сплаш, то сё, а потом начинает грузить и показывать что он при этом делает наводит мнея на мысли, что он грузит это всё опяять же в функции инициализации. Так как в случае с синглетонами, получилось бы не так.
Фотошоп бы висел три минуты после запуска, а потом бы казал сплэшскрин
A>3) Это просто глобальный объект со всеми его прелестями.
А что за проблемы в глобальных объектах, отличные от проблем синглетонов?
A>Вообще, надо иметь смелость сказать, что глобальные объекты эквивалентны синглтонам.
Ну я имею смелость заявить даже больше: "Синглетоны -- это и есть глобальные объекты. От синглетонов не надо ничего большего, по сравнению с глобальными объектами"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
A>>Вообще, надо иметь смелость сказать, что глобальные объекты эквивалентны синглтонам. E>Ну я имею смелость заявить даже больше: "Синглетоны -- это и есть глобальные объекты. От синглетонов не надо ничего большего, по сравнению с глобальными объектами"
Согласен. Вообще-то первоначально (когда компы были большими а программисты умными ) слово "синглтон" имело немного другой смысл. А именно "приложение, которое не позволяет запускать вторую (и последующие) копии самого себя". Т.е. если юзер запускал вордовый документ при уже запущенном ворде, то ворд не запускался заново, а уже существующий ворд открывал в новом окне документ, который пытался открыть юзер (как в ворд95 и ворд97). Но современные "орхитекторы" это значение слова синглтон благополучно забыли (ибо сложно в реализации, тут думать надо, понимаете ли), а додумались до класса с приватными конструкторами и запрещенными операциями копирования, единственным статическим объектом [возможно (если разработчику было не в лом) ] с отложенной инициализацией и статической функцией
и обозвали все это "паттерн проектирования синглетон". Так что я пока остаюсь лохом, который до сих пор использует статические мемберы с отложенной инициализацией и не использует синглетоны
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Всё это перекликается ещё с такой мыслью, что все эти библиотеки, паттерны и приёмы — это готовые решения типовых проблем. И если программист ещё не сталкнулся с этой проблемой, или скорее сталкнулся, но для него ещё не стало очевидно, что это проблема, и что хорошо бы иметь готовое решение для неё, у этого программиста такие вещи, конечно, не будут вызывать ничего кроме недоумения. Конечно он будет говорить, что это ненужное усложнение.
E>Я в целом согласен, что во всей теории есть и полезное. Я, например, зачем-то книжку таки почитал и Loki посмотрел E>Но на практичке я постоянно встречаю людей, которые применяют налево и направо навороты, и совсем не встречаю, таких, которые пишут плохо, потому что наворотов от Александреску не применили
Повезло
E>Ну на самом деле задачи просто проще методов Александреску. Увы, такая вот жизнь вокруг меня. Хотя программы в целом непростые, так скажем. И программисты квалифицированные.
Смотря какие подразумевать критерии хорошего решения задачи?
Если только наличие требуемого поведения, то тогда конечно любую задачу можно решить очень просто...
E>Ещё могу поделиться такой историей. У нас тут был недавно сотрудник, который очень хоршо знает и паттерны и STL и вообще всё. Настолько хорошо, что препадаёт это всё в одном уважаемом очень ВУЗе
А теоретиков вообще лучше до практики не допускать
Знаешь, возможно есть много докторов по химии, которые уже и не помнят как пробирки выглядят
Меня лично интересует только то, что начикается со слов practical или applied.
У нас тоже был один препод, который любил считать "так, значит у списка в этом случае вычислительная сложность будет O(1), значит используем список", эх, профайлер бы ему в руки
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Как бы то ни было, паттерны тоже не применяем, т.к. не все же студенты знакомы с ними. Ну оканчивается название класса на Visitor. Ну и что? Кому-то это ничего не скажет. R>>Так что 20 функций из С и ни фичей больше
E>Это всё крайности, а я за взвешенность и умеренность выступаю
Я согласен. Но видимо мы считаем, что уровень умеренности должен находиться на разных уровнях
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Erop, Вы писали:
КЛ>>>6) Шаблон Visitor (к своему сожалению юзаю в 1ом месте, а ты? Пременимость — пр. пункт) E>>Почему к сожалению и о чём именно ты сожалеешь? О том, что используешь или о том, что используешь один раз? E>>Мне известно о четырёх серъёзных попытках использовать этот шаблон. Все четыре провалились. То есть потом код был всё-таки переписан, без визитора и стал проще, лучше, понятнее и всё такое.
J>Вот здесь присоединяюсь. J>На мой взгляд, этот паттерн — один из самых неудачных.
Знаешь, Брюс Эккель тоже так считает — он прям в своей книжкке "Философия С++" так и написал об этом...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, remark, Вы писали:
R>Но этот подход гораздо более сложней и главное для его реализации надо знать гораздо больше: механизм распространения и перехвата исключений, политики обработки исключений, границы распространения исключений и т.д.
Давно программируете? Что-то выглядит всё это так, как будто вы вчера про исключения и шаблоны узнали и преисполнились чувства собственного достоинства. Исключения никак не относятся к самым сложным вещам из тех, которые должен знать профпригодный програмер.
Шаблоны как таковые тоже не ахти какая премудрость с точки зрения их использования, хотя и предоставляют извращенцам широкое поле деятельности. Заставь дурака богу молится ...
Что значит "механизм распространения и перехвата исключений" — средства ОС + их использование компилятором? Как это выглядит в ассемблере? Уверен, если того же Александреску спросить о том как реализован "механизм распространения и перехвата исключений" в Win и Visual C++ — вряд ли он детально знает, да оно и не надо (хотя и не мешат). Важно что этот механизм работает так, как того требует спецификация языка, а как он это делает — не так уж и важно.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>ИМХО, "стратегии", "паттерны" так бешенно популярны, потому как осилить все мировые запасы информации на эту тему проще, чем одну главу у Кнута. Потом ходишь и слова разные такие умные говоришь, все уважают. А какой прок от Кнута? (шучу, разумеется).
А>Положа руку на сердце — ведь то, что описано в любой лит-ре по дизайну/паттернам — доступно пониманию ребёнка. Берём для сравнения какую-нибудь книгу по, например, ЦОС, сжатию данных — упс — без определённой подготовки — далеко не уедешь.
А>Я не против паттернов, но: теоретическое знание паттернов — это то, что дёшего приобретают, но норовят дорого продавать. Спекуляцией попахивает. Любой нормальный программист с опытом от 3-5 лет и больше знает кучу паттернов, даже если никогда не штудировал эту тему специально. Пролистать соотств. лит-ру и такому не мешает, но каких либо великие откровения мало-мальски опытные программисты там вряд ли смогут обнаружить. Просьба не ссылатся на отдельных дебилов которые это утверждение якобы опровергают фактом своего существования.
Может быть и доступно пониманию ребенка СЕЙЧАС, но надо иметь в виду, что "Паттерны" Банды Четырех были выпущены в 1995 году, а написаны еще раньше. В то время многие в этой стране и не задумывались о том, что такое Наблюдатели, Посетители, Фабрики и прочее. Как никак этим идеям уже почти 12 лет, так что восхищаться и бить себя кулаком в грудь по поводу паттернов как-то глупо. Это просто классика, общий язык — и его надо знать.
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, Аноним, Вы писали:
А>Много вы от майкрософта про UML, паттерны и проч. слышите
Они просто называли их раньше по другому. Эти слова, которые вас так пугают, результат естественного процесса стандартизации.
> А покажите мне плоды трудов проповедников сложности и те огромные проекты, с которыми они справлись благодаря своим теориям.
Во-первых не проповедников сложности, а борцов с ней. А во-вторых
ВСЕ успешные крупные проекты. Начиная с винды.
А>Я не говорю что теже паттерны — плохо, в конце концов самой нужной половиной из описанных в лит-ре все и так всю жизнь пользуются, только до жуткой на них моды не знали, что это так называется.
Вот! В этом и суть. Не знали как называется. Знаешь почему провалилось строительство вавилонской башни? Каждый разговарил на своем языке.
То что написано в книге Александреску это одна из версий стандарта языка паттернов (программирования на языке предметной области) и компилятора для него (его роль пока что выполняют шаблоны С++). Естесствено слов в нем больше чем в языках программирования типа С++. Но и разница в качестве и производительности разработки программ примерно такая же, как у С++ и программировании непосредственно в машинных кодах.
И большинство проблем при применении паттернов вызвано как раз отсутсвием официального стандарта на язык паттернов и комплилятора с них. Если каждый реализует их по своему и подразумевает свое, о какой совместимости и упрощении может идти речь.
Хотя жалобы на сложность отладки шаблонов не имеют отношения к стандартизации. По мимо языка и компилятора нужен еще и отладчик более высокого уровня. Как при ошибке в программе на С++ отладчик может показать чистый машинный код и мы вынуждениы в нем разбираться, так и при ошибке в применении шаблона на показывают его кишки. Ошибки из рантайма переходят в компиляцию, что сильно улучшает надежность готовой программы.
Так же произошел естесственный процесс разделения программистов на архитекторов — пишущий на языке паттернов и кодеров — пишущих шаблоны на языке программирования. И читать заявления кодеров о том что они все могут написать без паттернов и шаблонов ей богу смешно. Все равно что "С++ маздай — ассемблер рулит". Сколько можно? Не боитесь остаться не у дел? Большую задачу можно решить сложно простыми средствами, но проще сложными
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Некоторые виды дублирования нельзя устранить ни какими способами, кроме advanced-templates (не считая таких отстойных вещей как макросы и void*).
R>>Моё обоснование использования advanced-templates в двух указанных выше предпосылках.
R>>По мимо очень большой скорости правки кода, тебе так же понадобиться идеальная внимательность, т.к. при исправлении какого-либо аспекта в паре десятков мест надо везде сделать правильно.
R>>Идеальной внимательностью я кстати тоже не обладаю, поэтому не люблю, когда мне приходится "поправлять" десятки "почти похожих мест" в проекте.
E>Прекрасно! E>Расскажи как тебе помогают в твоих многочисленных бедах мультиметоды и for_each
E>Главная проблема с шаблонами, ИМХО, такая, что часто при редактировании нетривильного шаблона очень трудно предсказать все последствия. E>Так что кроме идеальной внимательности нужна ещё и идеальная проницательность, доходящая до уровня провидца
Товарисчъ, вы когда-нибудь успокоитесь
Нука их, эти шаблоны
R>>Я совершенно согласен, что мультиметоды вещь достаточно редкая, поэтому к ним такое и отношение. Но А тут совершенно ни при чём. Он лишь предложил достаточно хорошую реализацию мультиметодов. Но в том, что это редкая вещь, он не виноват. E>Крнечно не виноват! Это его заслуга, что он смог придумать столь редкую задачу и решение для неё. Просто вся эта штука очень далека от реальной жизни E>А виноват чувак, который решает внедрить мультиметоды туда, где они не нужны. Потому что так "покруче" будет
Назначение мультиметодов помоему хорошо описаны у Саттера (Правило 31 кажется). Я их лично использовал для реализации физики при разработке движка игры.
E>А что касается примера с поведениями, то от чего бы поведение не задавать парой интерфейсов?
Вот это как раз и называется стратегиями (политиками, аспектами), о которых пишет Александреску.
Сторонники "старых и простых" технологий предпочитают создавать в этом случае 50 классов с помощью множественного наследования или более "продвинутые" используют макросы.
Здравствуйте, qqqqq, Вы писали:
Q>Книжка Александреску хороша, нет слов, да только не всегда все это все в пользу. Если програмируешь в основном один и очень хорошо в этом сам разобрался то конечно, да... А если работаешь в большой разнородной команде с текучкой где не все С++ программисты про итераторы слышали, то применение изощренных приемов из этой книги может заметно мешать. Только "избранные" смогут этот код понимать даже в приципе а поддерживать все "это" придется самому. Если поручат исправить простую ошибку менее квалифицированному кадру то он запросто там таких дров наломает, что все равно потом к тебе прибегут за помощью, когда гром грянет. Но если тайная цель все под себя подмять в такой разнородной команаде то да, надо напихать в программу побольше патернов, темплейтов из этой и других подобных книг, замешать с STL, Loki, boost и АСЕ, и еще написать описание соответствено — цены тебе не будет. Видел я и проекты написанные на "обычном" C++ и исключительно advanced код, так вот те простые чаще были более удачные. Q>Другие отностительно новые книжки по "продвинутому" C++ — Exceptional C+, More Exceptional C+, Effective STL, C++ Templates: The Complete Guide, и еще может пара книжек то ACE
Если менее квалифицированный кадр чего-то не знает — это не повод не использовать это "чего-то". Могу сказать по собственному опыту — большой проект с большой текучкой программистов, которые не слышали про итераторы( причем тут А. не понимаю, он про них не пишет и не он их придумал.) — это самоубийство. И мне наплевать, слышали они про std::vector или нет, мне нужна надежная работающая программа и от std::vector из-за какого-то Васи(Феди...) я от него не откажусь, лучше от Васи(Феди...) откажусь, пусть технологии учит...
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>И эту библиотеку тоже придётся поддерживать вместе с проектом. Т.ч. дублирование не умесно. А в с++, к сожалению, только самые примитивные виды дублирования можно устранить с помощью обычных функций. Если можно с помощью функции, то я конечно не против такого простого решения. Но часто просто не получается с помощью функции. Часто только ОО-подходы могут устанить дублирование. А часто и ОО-подходам это не под силу, тогда как-раз шаблоны и приходят на помощь (заметьте речь идёт о прикладном проекте). А иногда и шаблонам не под силу устранить дублирование, ну уж тогда на помощь приходят всеми нами любимые макросы.
E>да всё таки и есть в целом. E>Только прикольно, что в качестве крайнего средства предлагаются не шаблонные шаблонные параметры, как у А., а макросы
Я объяснил почему — некоторые виды дублирования подвласны только им.
E>Но это всё не про книжку А. E>Там предлагаются навороты, которые ИМХО ни в каком реальном проекте не пригодятся
Ну я уже понял, что ты научился очень быстро набирать/править код (здесь
). Я лично не достиг такого мастерства, мне лично не нравится дублирование, поэтому я готов менять часть простоты кода на устранение дублирования.
Некоторые виды дублирования нельзя устранить ни какими способами, кроме advanced-templates (не считая таких отстойных вещей как макросы и void*).
Моё обоснование использования advanced-templates в двух указанных выше предпосылках.
По мимо очень большой скорости правки кода, тебе так же понадобиться идеальная внимательность, т.к. при исправлении какого-либо аспекта в паре десятков мест надо везде сделать правильно.
Идеальной внимательностью я кстати тоже не обладаю, поэтому не люблю, когда мне приходится "поправлять" десятки "почти похожих мест" в проекте.
Здравствуйте, remark, Вы писали:
E>>Я конечно согласен, что сложнее. Но про "людей, занкомых поверхностно" -- это немного мимо кассы. Конструкции из Loki не годятся даже для людей неповерхностно знакомых с шаблонами Они просто слишком сложные.
R>Я тебя уверяю, что есть вещи гораааздо более сложные, и при этом люди, которым это надо разбираются в них очень хорошо. R>Как пример, могу привести некоторые раздели физики — типа квантовой механики, СТО и т.д.
ИМХО СТО весьма несложна, но это не важно.
Имелось в виду, конечно "слишком сложные для решения возникающих на практике задач"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Аноним, Вы писали:
А>ИМХО, "стратегии", "паттерны" так бешенно популярны, потому как осилить все мировые запасы информации на эту тему проще, чем одну главу у Кнута. Потом ходишь и слова разные такие умные говоришь, все уважают. А какой прок от Кнута? (шучу, разумеется).
А>Положа руку на сердце — ведь то, что описано в любой лит-ре по дизайну/паттернам — доступно пониманию ребёнка. Берём для сравнения какую-нибудь книгу по, например, ЦОС, сжатию данных — упс — без определённой подготовки — далеко не уедешь.
А>Я не против паттернов, но: теоретическое знание паттернов — это то, что дёшего приобретают, но норовят дорого продавать. Спекуляцией попахивает. Любой нормальный программист с опытом от 3-5 лет и больше знает кучу паттернов, даже если никогда не штудировал эту тему специально. Пролистать соотств. лит-ру и такому не мешает, но каких либо великие откровения мало-мальски опытные программисты там вряд ли смогут обнаружить. Просьба не ссылатся на отдельных дебилов которые это утверждение якобы опровергают фактом своего существования.
Супер! А то развели истерию- паттерны, шаблоны проектирования, мы крутые раз можем писать шаблонный код и имеем "шаблонное" мышление. А задачи для школьников 6-го класса (математического) никто решить не может. Реально сложные вещи- алгоритмы и логические задачи. В С++ и шаблонах/паттернах/whatever ничего сложного нет.
Здравствуйте, remark, Вы писали:
R>Это относится и к явным интерфейсам. Они хорошо описывают лишь сигнатуры функций. Не больше и не меньше.
<...много пропущено...> R>Потом "если ты не можешь создать экземпляр, ты должен возвращать -1, а не 0! ну ты блин даёшь!"
Ну идея возвращать -1 под видом указателя не может не радовать, а так в целом я с тобой согласен. Жизнь программистов и так трудна и Договориться между частями большого проекта и так непросто. Зачем это всё усугублять ещё и при помощи шаблонов?
R>Сигнатура функции — это лишь вершина айсберга. Это самая тривиальная часть. R>Забывают комментировать и проверять (или скорее просто не думают об этом) как раз самые тонкие моменты
Проблема в том, что при программировании шаблонов тоже забывают, а момнетов намного больше. Поинт в том, что шаблоны обычно дают слишком много свободы. ЧТо и приводит к проблемам
E>>1в) Не понятно что делать, когда этот коментарий устаревает. Формальных проверок или нет или они чудовищны и ненадёжны. Вот понадобилось тебе, чтобы, скажем, сделать fff возвращал const MyInt&? Что вот делать? Вычитывать весь клиентский код во всех сделвнных на этом шаблоне проектах?
R>см. выше. Проблема неактуальности документации не имеет ничего общего к шаблонам.
Не совсем так. В C++ шаблонах очень прохо разделены интерфейс и реализация.
Вот правишь ты какой-то шаблонный класс. Переименовываешь приватные методы там, поля, ещё чего делаешь.
А у пользователя были частичные специализации каких-то методов твоей мульки. И что дальше делать?
R>А если например функция virtual SomeClass* fff() = 0; раньше была сама ответственна за удаление созданных экземпляров, а тебе понадобилось, что бы она пересала быть ответственна и не удаляла их. Что ты будешь делать? Вычитывать весь клиентский код во всех сделанный на этом интерфейсе проектах?
Лично я старую функцию оставлю для обратной совместимости, объявлю её obsolete, а для современного, правильного использования заведу функцию с другим названием.
А ты как поступаешь?
R>Решение: реализовать прототип класса, которым можно инстанциировать шаблон не в комментарии а в коде. И в каком-то месте инстанциировать им шаблон, что бы он компилировался, но не выполнялся. Проблема устаревания и полноты решена. R>Я согласен, это сложнее, чем явный интерфейс, для этого надо обладать знаниями, что бы так сделать.
R>Далее — static_assert — с их помощью можно проверять уже классы, которыми пользователь специализирует твой шаблон. Проверить можно много. И даже больше, чем ты можешь проверить с помощью явного интерфейса! R>Согласен, это опять же сложнее. Опять же надо обладать некими знаниями.
Не понятно ни зачем это нужно (что ускорится, удешивится и т. д), кроме того не понятно кто гарантирует, что ты своим примером исчерпаешь фантазию пользователей.
R>Далее — решение уже не только для шаблонов. Оно и явным интерфейсам костыли прикрутит. Модульные тесты. Проверяем горааааздо больше, чем явный интерфейс. Проверяем, кстати, и то, что virtual SomeClass* fff() = 0; сама удаляет память, и что она потокобезопасна, и что она не уидает исключения, и что в случае ошибки она возвращает именно -1.
Модульные тесты уведут нас очень далеко от темы обсуждения книжки Александреску.
Но в целом я согласен, что модульные тесты позволяют до какой-то степени улучшить качество кода, за счёт удорожания разработки. Если конечно вдруг их в каком-то проекте удаётся сделать и заставить нормально работать (не в смысле кодирования и отладки, а в смысле налаживания бизнес-процессов). Но я не понимаю почему плюсом является такое усложнение кода, при котором модульные тесты из полезных в некоторых критичных именно по качеству проектах становятся необходимыми повсеместно?
Может это говорит таки о том, что что-то мы таки переусложнили? E>>Кроме того, есть у меня такое практическое наблюдение, что когда кто-то пишет шаблон и он при этом не супер спец этого дела, то получается изделие с неясной семантикой. Обычно я не придираясь, а просто стараясь понять что и как там втыкается, задаю вопросы, которые ставят авторов в тупик
R>При чём здесь шаблоны? R>Я видел и обычные функции из 10 строк с неясной семантикой.
Шаблоны тут при том, что если средний программист пишет функцию, то она с ясной семантикой. А если шаблон -- то нет. Просто потому, что у функции намного лучше определён интерфейс, то есть есть хорошее место где подумать над семантикой
Но в целом я повторяю в чём именно я с тобой не согласен по существу.
Я всё-таки считаю, что чем проще и понятнее написана программа, тем лучше она написанна. Бывают действительно сложные задачи, где нужны сложные решения, тогда навороты реально упрощают программу. То есть вот вычислитель таблиц Брагиса, например, на С++ писать проще, чем на ассемблере, хоя ассемблер и проще. Но всё ещё его проще писать на С++, чем на С++, но с переносом всех вычислений в CT.
А ты считаешь, что если можно усложнить что-то, то надо. Ну и что, что для этого "Опять же надо обладать некими знаниями." и что это "Согласен, это опять же сложнее.". Но ведь если ещё и такой assert прикрутить и сякой и тесты модульные наладить, то типа бкдт нам счастье. А я не понмаю зачем. Единственный заметный мне эффект -- разработка требует больше времени, более продвинутых, то есть дорогих, программеров и становиться труднее в отладке и поддержке. А плюсы-то какие?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Вот это как раз и называется стратегиями (политиками, аспектами), о которых пишет Александреску. R>>Сторонники "старых и простых" технологий предпочитают создавать в этом случае 50 классов с помощью множественного наследования или более "продвинутые" используют макросы.
E>Не, Александреску обычно пишет о навёрнутых конструкциях их шаблонов. А я написал о структуре из нескольких указателей на интерфейсы.
"Навёрнутые" или не "навёрнутые" — это субъективное мнение. Мне сейчас это не кажется навёрнутым. Просто другая форма записи тем же самых вещей. Не вижу никакой принципиальной разницы между включением нескольких указателей на динамические интерфейсы или включением нескольких указателей на статические интерффейсы. Синтаксис немного другой. Да, у шаблонов синтаксис порядочно сложнее, с этим согласен. Вначале снепривычки было сложно, но сейчас практически одинаково.
Здравствуйте, Константин Л., Вы писали:
E>>А так нормально всё. Но я так понял, что визитёр там был таки с горяча? КЛ>50/50 КЛ>С одной стороны можно было обойтись if'ми, с другой код стал более строже
Ну скажем так, что этот пример меня не убедил
Мне кажется, что место вообще простое, понятное, и какой визитор не привенти -- сильно не испортишь, но в принципе без визитора проще
Хотя для "потренироваться" полигон выбран грамотно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>accumulate, как мне кажется, не читабельнее чем for, copy тоже. E>merge -- уже чем-то лучше, но нужен редко E>Мапы и сортировку я использую из конторской библиотеки примитивов.
Код, в котором используется STL более переносим, чем "конторская библиотека", хоть, может быть, и менее удобен для каких-то задач.
По поводу переносимости кода с использованием STL — ниже.
E>Хотя и qsort ничем таким особенным не плох. Главный недостаток -- непереносим.
В отличие от функции qsort, алгоритм std::sort является шаблонной функцией, и в силу этого у него есть несколько серьезных, IMHO,
преимуществ:
-типобезопасность;
-большая гибкость за счет возможности реализации предиката сравнения как просто функции/оператора,
так и полноценного класса, содержащий некоторый контекст.
-обычно предикаты сравнения реализуются как шаблонные классы, объекты которых в алгоритм передаются по значению,
или перегруженные операторы. Это позволяет компилятору встраивать код операции сравнения непосредственно
в тело алгоритма, что позволяет исключить накладные расходы на ее вызов. С qsort это сделать нельзя, так
как компаратор всегда передается в нее как указатель на функцию, которая внутри qsort должна вызываться по
указателю, что автоматически делает встраивание функции сравнения невозможным.
E>Например разные реализации qsort (впрочем как и разные реализации stl) по-разному сортируют массив, в котором встречаются равноценные элементы.
Можно вспользоваться вместо std::sort алгоритмом std::stable_sort, который сохраняет порядок следования одинаковых элементов при сортировке.
E>Ну вот мне примеры использования Loki позитивные не известны.
На счет Loki не знаю, но для Boost здесь есть
список компаний, которые используют его (некоторые в том числе и Boost.MPL ) для реализации коммерческих проектов,
а здесь список компаний, которые используют Boost для внутренних разработок.
Как видно, некоторые считают использование наворотов (в том числе и списков типов в MPL) вполне оправданным
для реализации реальных коммерческих проектов.
E>Мало того, про "сложность под капотом" я уже писал. Обычно я сижу как раз под этим капотом и пытаюсь понять кто же и что накосячил в клиентском коде, E>что эту прекрасную и мощную библиотеку так загнуло-заломало?
Я думаю, что кривые руки могут сломать любую библиотеку , по этому мне это не кажется весомым аргументом.
J>>...А со SmartPtr и правильной стратегией это можно автоматизировать и вообще сделать зависимым от режима компиляции (в смысле, #ifdef _NDEBUG), когда в релизе он будет вести себя как голый указатель.
E>Собственно поинт состоит в том, что всё это виликолепие не нужно E>Мне вполне хватает трёх умных указателей. Один для COM-объектов, и он не наш, а баблиотечный, один просто scope_guard, с запретом копирования. (На самом деле он бывает векторным и скалярным, но первый мне пока что не пригождался). Првда по историческим причинам он давно очень у нас реализован и им и пользуемся. И ещё один со счётчиком. Он предполагает, что имущество, которым он владеет является public virtual наследником некоего класса, в котором реализован счётчик. E>Собственно больше мне ничего от умных указателей ни разу не понадобилось.
Зато это "великолепие" может быть нужно многим другим разработчикам.
E>Дампить логи, для отладки. Решать нужно ли удалять все элементы коллекции, считать есть ли утечки памяти и т. д. ИМХО надо не в умном указателе, а в специализированных средствах. E>В нашей библиотеке, например (так же как и в crt-куче, кстати) есть средства контроля утечек, для проверки всё ли хорошо я традиционно пишу методы IsValid, для записи логов или save'ов использую соответсвующие стредства и не испытываю ни малейшей потребности вставить всю эту нужную и полезную функциональность в какой-нибудь умный указатель
Я считаю, что выбор средств реализации проекта, в данном случае — библиотек, завист от конкретной ситуации.
Если у вас есть готовая библиотека, которая удовлетворяет вашим требованиям, то целесообразно ее и использовать.
В такой ситуации вряд ли кто-то будет переходить на что-то другое без особой необходимости.
С другой стороны, если ничего готового нет, то может быть лучше взять взять готовые решения из boost или Loki,
чем писать свои велосипеды. Тем более, что библиотеки Boost писали достаточно квалифицированные разработчики,
у него достаточно большой круг пользователей, которые могут найти и исправить баги,
а также проконсультировать по проблемам использования.
Loki конечно далеко не идеал, но ведь она изначально, насколько я понимаю, была предназначена для иллюстрации
идей Александреску, а не для промышленного применения. Тем не менее том же Boost кое-где используются
подходы, аналогичные реализованным в Loki.
E>Короче мне кажется, что лучше иметь продуманную библиотеку, простую, и ясную, как в использовании, так и в поддержке и отладке, как клиентского кода, так и кода баблиотеки. А не нереально сложный со всех сторон универсальный всемогутер, который предоставляет два миллиона ненужных возможносетй наряду с пятью из шести нужных.
Это, конечно, очень правильно сказано, да ведь не так много специалистов, которые способны спроектировать
и реализовать гибкие, легко расширяемые библиотеки, удобные в использовании, обеспечивающие высокую производительность,
защищенные от неправильного использования, да еще и работающие на разных платформах и компиляторах.
И я не думаю, что в каждой конторе такие специалисты найдутся. Так что иногда выгоднее и проще использовать готовые решения,
"с наворотами", но решающие эффективно поставленные задачи, чем писать велосипеды.
J>>SmartPtr — достойная задача? Имхо, почти на каждом шагу. SmallObjectAllocator? (Не помню, правда, совместим ли он с STL, если да, было бы вообще здорово — можно было бы рожать всякие std::map<int, double>, не особо боясь за эффективность.) E>Ну, на мой взгляд, SmartPtr, SmallObjectAllocator и даже STL и C++ -- это не задачи, а средства. А задача, это например: "разработка автоматической коробки передач, которая не нуждается в более мощном двигателе, чем механическая, при равном комфорте вождения". E>Или "Разработка обучающей игры, которая позволяет ненавязчиво и в игровой форме достичь обучаемым детям таких-то и таких-то результатов". Или, даже, (что ближе всего к книжке А., кстати ): "Заработать $100 000 000", но никак не SmartPtr
Согласен, решение самой поставленной задачи гораздо важнее выбора средства реализации.
Но при реализации больших проектов возможность расширения/развития/добавления функциональности тоже является
немаловажной частью этой самой задачи. И здесь решения с "наворотами", но более гибкие, могут быть
предпочтительнее "простого" кода. Опять же, все зависит от конкретной ситуации.
E>>>Мне нравится парадигма "сделать так просто, как только можно". J>>Сам Александреску придерживается того же мнения http://rsdn.ru/Forum/Message.aspx?mid=1850161&only=1
E>Да я знаю. Я скромно считаю, что мы с ним единомышленники. И что Loki -- это можельная библиотека. Она в оснвоном демонстрирует каких можно приколов напрограммировать на C++, а не как надо писать полезные и хорошие программы E>В целом мне интересно было читать, что там такоего прикольного придумал А. E>Но мне не прикольно, когда так начнают программировать, и тем более неприкольно, что начинают стримиться к такому стилю те, кто так программировать ещё не умеет
Так это относится к использованию любых средств языка и при использовании любых парадигм программирования.
Бездумное примение чего-либо всегда приводит написанию кода, который проще выбросить и переписать заново.
J>>так алгоритмы подключаются через #include <algorithm> явно J>>Это во-первых, а во-вторых, конкретно к вектору это никакого отношения не имеет, сам знаешь, алгоритмы работают на уровне итераторов (аналог указателей). E>Ну может имеет, а может не имеет, а вот итераторы в вектор вкопаны по пояс, хотя мне они занафиг не нужны. Толкьо вредят.
Может просто не использовать эти лишние для вас особенности? Например с стандартах кодирования явно запретить использовать все,
что связано с итераторами.
E>Мне, кстати, в std::vector еще не нравится, что в operator[] не проверяют границ.
Да, в operator[] нет проверки допустимости индекса, чтобы его могли использовать
без потери производительности те, кому эта проверка не нужна. Кому проверка нужна
могут использовать std::vector::at () вместо std::vector::operator[]().
В лучае выхода индекса за допустимы границы at() бросает исключение.
E>Но память обычно портят как0нибудь вычурно. Например недавно одному программисту нужно было добавить в узлы некоего дерева своё поле. При этом тип узла он менять не мог. Мало того, это поле использовалось для того, чтобы это дерево строить. E>Он сделал так. Завёл map из указателей на узлы дерева в эти самые поля. Добавлял эти поля в map по требованию И было ему чсастье, пока при построении дерева он не начал удалять некоторые узлы E>map он при этом не чистил, но иногда доставл из него указатели на вершины. Ну и на этом прекрасном пути память и портил. E>а проявлялась проблема в другом месте, где другой достойный мужчина использовал stl. Проблема проявлялась на merge. Я довольно долго всё это счастье отлаживал.
А что бы изменилось, если бы использовались самописные функции/классы, а не из STL?
Разве что в реализации STL обычно используются так сказать, "обфусцированные" имена переменных и объектов, поэтому отлаживать
ее труднее.
E>Не зняю. Я наш код много куда переносил. И скажу так, что ИМХО STL переносимость понижает! Причём делает это в плохопредсказуемых местах И это один из его многочисленных недостатков
Вообще гворя STL — это просто описание в Стандарте некоторых интерфейсов и некоторых требований к их реализации.
Так что переносимость как таковая зависит от того, кто ее _реализует_.
Если же требуется действительная переносимость с платформы на платформу, то что мешает использовать STLPort (здесь список поддерживаемых компиляторов)
или SGI STL?
E>>>Я ещё раз призываю рассказать где же оно всё бывает нужно-то? J>>Ну уже сказал. В "Прикладных вопросах" был топик про реальное использование boost::mpl — посмотри еще там. J>>У меня лично сколь-нибудь нетривиальное использование шаблонов в основном сводится к traits, большего сановский компилятор просто не позволяет. E>Про mpl я говорить не хочу, так как все известные мне случаи "выгод" от его применения носят чисто идеологический характер. Ну нравится людям так, хотя мне кажется, что так получается сложнее, чем иначе.
Есть сложность написания и сопровождения, а есть сложность использования. Да и сложность восприятия конкретного кода меняется от программиста
к программисту, а также для одного и того же программиста с течением времени.
E>Я собственно просил рассказть о случае удачного применения loki
Судя по всему, тут уже пошел разговор о применимости STL и решениях, примененных Александреску в Loki, в реальной жизни.
Я Loki не использую, но кое-какие идеи его я применяю при написании своего кода. Boost, где используются
кое-какие аналогичные решения, я использую по мере надобности (там есть много полезных вещей и без "наворотов").
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень . А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, LaptevVV, Вы писали:
LVV>>Знаешь, Брюс Эккель тоже так считает — он прям в своей книжкке "Философия С++" так и написал об этом...
J>Какой я умный, оказывается J>Что, книжка стоит того, чтоб ее прочитать?
Первый том — ликбез для совсем новичков... Хотя очень близко к стандарту...
Второй том — ликбез для начинающих профессионалов...
Там есть основы, как делать CppUnit, естественно, про шаблоны и обобщенное программирование, STL довольно подробно... Основы паттернов — на элементарных примерах...
В общем, как раз — как только научился основам С++ — первая книжка после этого...
Профессионалам — скучно...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Erop, Вы писали: Q>><...>Но если тайная цель все под себя подмять в такой разнородной команаде то да, надо напихать в программу побольше патернов, темплейтов из этой и других подобных книг, замешать с STL, Loki, boost и АСЕ, и еще написать описание соответствено — цены тебе не будет...
E>Если программист стал незамениным, его пора увольнять (с) не помню кто
Это теоретики... Ни разу не видел ничего подобного. Задача тимлида проследить за необходимостью "навороченности" кода и дизайна.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, alexeiz, Вы писали:
A>>А вообще, книга описывает основные паттерны проектирования, которые нужно уже давно знать и использовать самому. Нельзя изучать паттерны по книге Александреску. Нужно прочитать Gang of Four и попробовать делать так как там написано. А потом, когда надоест писать горы однотипного кода и появиться желание как-то автоматизировать этот процесс, то тут приходят на помощь идеи Александреску.
A>>Если ты не используешь паттерны. Александреску тебе ничего не даёт, а просто сотрясает воздух в пустую.
E>Я бы так сказал, что про паттерны можно поговорить особо. E>Вообще есть некоторое кол-во паттернов, действительно полезных и попадающихся в реальности. E>Но большинство из них -- ИМХО вещь в себе, возникшая от необходимости двишать науку, а не из практических соображений.
Без конкретных примеров твоё утверждение не имеет большой силы. Что ты имеешь ввиду под большинством? Откуда ты берешь паттерны, из которых большинство является вещью в себе? Вот я для примера взлянул на паттерны из Gang of Four. Больше половины (т.е. большинство) паттернов я могу описать только глядя на название. Соответственно я их характеризую как действительно полезные и попадающиеся в реальности.
E>Ну а Александреску -- это уже пожалуй вторая производная.
Т.е. ты хочешь сказать, что так как паттерны по большей части вещь бесполезная, то описанные в Александреску будут бесполезными в той же пропорции. Давай возьмём паттерны описанные в Александреску, и ты скажешь, что из них вторая производная:
Я бы сказал, что всё кроме мультиметодов из этого списка является действительно полезным и часто применяемым.
E>А вообще интересно, почему тебе кажется, что скорее LISP, а не Prolog?
Typelists, head, tail, рекурсивные обработки списков — это Lisp чистой воды.
Здравствуйте, Erop, Вы писали:
E>Возможно решат, возможно не решат. Я так думаю, что решат, но не ту. E>Но в текущем полложении дел есть несколько пробоем. E>1а) Никто не гарантирует тебе, что этот твой комментарий соответсвует действительности. Вдруг *на самом деле* ты требуешь от TLog чего-то ещё. Или, наоборот, чего-то пока что не требуешь?
Об этом ниже
E>1б) НИкто не гарантирует, что твой комментарий будет правильно понят пользователем. Вдруг он напишет метод int& fff()? И в текущей версии шаблона всё будет хорошо, а потом ты что-то захочешь поправить? А формальной проверки не выполняется.
Это относится и к явным интерфейсам. Они хорошо описывают лишь сигнатуры функций. Не больше и не меньше.
Они не описывают ни семантику функций, ни требования к многопоточности и др. гораздо более сложные и тонкие моменты.
Вот ты говоришь о шаблонных функциях, что может быть int& fff(), а может быть int fff() и шаблон может это не различить.
Представь тебе дали реализовать интерфейс:
/** Интерфейс такой-то такой-то */struct Interface
{
/** Функция, которая создаёт экземпляр SomeClass
*/virtual SomeClass* fff() = 0;
};
Ты думаешь — элементарно. Явный интерфейс есть. Что ещё надо? Реализовал.
Потом тебе говорят "у тебя утечка, ты сам ответственнен за удаление экземплятор SomeClass, а ты их не удаляешь!"
Через день "из-за твоего кода у нас всё падает! Метод fff() должен быть потокобезопасен! Ты что не знал, это все уже знают"
Через неделю "Блин, ну ты и накосячил! Из fff() нельзя кидать исключения! Делай с ними что хочешь, но выпускать из fff() их нельзя!"
Потом "если ты не можешь создать экземпляр, ты должен возвращать -1, а не 0! ну ты блин даёшь!"
Сигнатура функции — это лишь вершина айсберга. Это самая тривиальная часть.
Забывают комментировать и проверять (или скорее просто не думают об этом) как раз самые тонкие моменты
E>1в) Не понятно что делать, когда этот коментарий устаревает. Формальных проверок или нет или они чудовищны и ненадёжны. Вот понадобилось тебе, чтобы, скажем, сделать fff возвращал const MyInt&? Что вот делать? Вычитывать весь клиентский код во всех сделвнных на этом шаблоне проектах?
см. выше. Проблема неактуальности документации не имеет ничего общего к шаблонам.
А если например функция virtual SomeClass* fff() = 0; раньше была сама ответственна за удаление созданных экземпляров, а тебе понадобилось, что бы она пересала быть ответственна и не удаляла их. Что ты будешь делать? Вычитывать весь клиентский код во всех сделанный на этом интерфейсе проектах?
Решение: реализовать прототип класса, которым можно инстанциировать шаблон не в комментарии а в коде. И в каком-то месте инстанциировать им шаблон, что бы он компилировался, но не выполнялся. Проблема устаревания и полноты решена.
Я согласен, это сложнее, чем явный интерфейс, для этого надо обладать знаниями, что бы так сделать.
Далее — static_assert — с их помощью можно проверять уже классы, которыми пользователь специализирует твой шаблон. Проверить можно много. И даже больше, чем ты можешь проверить с помощью явного интерфейса!
Согласен, это опять же сложнее. Опять же надо обладать некими знаниями.
Далее — решение уже не только для шаблонов. Оно и явным интерфейсам костыли прикрутит. Модульные тесты. Проверяем горааааздо больше, чем явный интерфейс. Проверяем, кстати, и то, что virtual SomeClass* fff() = 0; сама удаляет память, и что она потокобезопасна, и что она не уидает исключения, и что в случае ошибки она возвращает именно -1.
E>Кроме того, есть у меня такое практическое наблюдение, что когда кто-то пишет шаблон и он при этом не супер спец этого дела, то получается изделие с неясной семантикой. Обычно я не придираясь, а просто стараясь понять что и как там втыкается, задаю вопросы, которые ставят авторов в тупик
При чём здесь шаблоны?
Я видел и обычные функции из 10 строк с неясной семантикой.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Аноним, Вы писали:
А>>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
E>1) Мне нравится книжка Александреску (которая современное проектировнаие на C++). Но странною любовью нравится. E>Собственно она позволяет понять насколько программист является грамотным инженером. Если книжка нравится и хочется немедленно всюду это дело применять -- то точно инженер плохой. Если уж с таким и сотрудничать, то очень внимательно контролировать чего он там напрограммировал. Точно ли не переусложнил?
Если этого требует задача, и это решение проанализировано, то почему нет?
E>2) Во-вторых, эта книжка мне нравится потому, что там очень хорошо и на примерах описано насколько плохо программировать таким образом
Сложно — бесспорно, плохо — смотря для чего.
E>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет
А. тут ни при чем, шаблоны сами по себе сложны. Ты против А. или против шаблонов? Мне кажется 2-oe.
E>4) Ну и главное. В целом очень редко в программировании попадаются такие сложные задачи, что нужно то, что описано у Александреску скажем. Конечно теоретикам программирования на C++ реальные сложные практические случаи (скажем написаение графического редактора с каими-то хитрыми особенностями, или там системы распозанавания речи или ещё чего), а уж тем более какие-то простые и распространённые (скажем написание Web-интерфейса к какой-то БД) совсем уже не интересны. Потому что там уже трудно придумать что-то реально хорошее и нужное. А интересны либо какие-то извраты на почве синтаксиса, либо решение каких-то сверхсложных архитектурных задачь, в реальной жизни совсем не возникающих. E>Но при этом не особо опытные инженеры этого всего не понимают и очень сильно переусложняют код.
E>Так что очень может быть, что стиот почитать вские умные книжки на эту тему, особенно про паттерны проектирования, но главная идея должна быть такая, что никогда не забывать точно ли это нужно для реально возникающих в твоей деятельности задач.
Золотые слова. Но если ты в своей деятельности не встречаешься с задачами, которые требуют применения таких извращений, это не значит, что другие не встречаются.
E>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов. E>Просто такие программы писать труднее и требуется более высокая квалификация. Но, ИМХО, стремиться надо к этому, а не к созданию мегасупержутких наворотов. E>Хотя для эрудиции эти все нароботки просмотреть конечно стоит
Я бы не был столь категоричным. Большинство того, что он там пишет можно и нужну использовать. Просто надо знать "что?где?когда?". Никто не говорит о использовании typelists в приложении на 20 .h/.cpp., которое кажет 1 диалог с 2-мя кнопками... Если я не ошибась, А. сам пишет о том, что нужно искать компромиссы, здравые решения для каждой конкретной ситуации.
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр.
Попробуй вначале разобраться с STL. Я Александреску читал, был в восторге. Однако на практике применить материал удаётся крайне редко. Так что можно особо не торопиться с современным программированием. Оно, как искуство каллиграфии, уходит в область, далёкую от практических задач.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
КЛ>>Если менее квалифицированный кадр чего-то не знает — это не повод не использовать это "чего-то". Могу сказать по собственному опыту — большой проект с большой текучкой программистов, которые не слышали про итераторы( причем тут А. не понимаю, он про них не пишет и не он их придумал.) — это самоубийство. И мне наплевать, слышали они про std::vector или нет, мне нужна надежная работающая программа и от std::vector из-за какого-то Васи(Феди...) я от него не откажусь, лучше от Васи(Феди...) откажусь, пусть технологии учит...
E>Я согласен с тобой, что от std::vector стоит отказываться только в случае если есть что-то лучше. Так как хуже уже точно опускаться не стоит. E>Но вот от списков типов и от Loki я бы отказался однозначно во всех известных мне проектах. E>Хотя "бы" тут даже лишнее. Пока что я во всех отказался
Да я тоже их не использую, но это не значит что они сакс и нигде не пригодны. Если появится задача, при решении котрой они мне помогут, я буду их использовать.
Здравствуйте, Константин Л., Вы писали:
E>>>>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.
КЛ>Хорошая программа — это: КЛ>1) программа, котрая делает то, что нужно КЛ>2) имеет мало багов КЛ>3) которую легко сопровождать и добавлять функционал
Я согласен со всем, кроме быть может "добавлять функционал", и то не так чтобы я спорю, но формулировка мне не нравится. Я бы предпочёл написать "развивать в соответсвии с потребностями потребителей"
Ну и два бы я расширил в сторону "легко отлаживать".
Собственно я в выделенном абзаце и утверждаю, что обычно boost, loki, etc портят 3, 2, и как следствие и 1
Да ещё и удорожают разработку, так как не каждый программист затянет применить все эти прелести не слишком разрушительно
Собственно содержание моего утверждения такое. Но я так ине понял согласен ты с ним или нет.
КЛ>Всем нравится простой код, а "крутой" еще больше
А какой код "крутой"? Ты что имеешь в виду? У меня есть подозрение, что "крутой код" мне не нравится.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>А ты считаешь, что если можно усложнить что-то, то надо. Ну и что, что для этого "Опять же надо обладать некими знаниями." и что это "Согласен, это опять же сложнее.". Но ведь если ещё и такой assert прикрутить и сякой и тесты модульные наладить, то типа бкдт нам счастье. А я не понмаю зачем. Единственный заметный мне эффект -- разработка требует больше времени, более продвинутых, то есть дорогих, программеров и становиться труднее в отладке и поддержке. А плюсы-то какие?
сам же и ответил (см. выделенное)
Разве этого мало?
Здравствуйте, Erop, Вы писали:
КЛ>>Хорошая программа — это: КЛ>>1) программа, котрая делает то, что нужно КЛ>>2) имеет мало багов КЛ>>3) которую легко сопровождать и добавлять функционал
E>Я согласен со всем, кроме быть может "добавлять функционал", и то не так чтобы я спорю, но формулировка мне не нравится. Я бы предпочёл написать "развивать в соответсвии с потребностями потребителей" E>Ну и два бы я расширил в сторону "легко отлаживать".
E>Собственно я в выделенном абзаце и утверждаю, что обычно boost, loki, etc портят 3, 2, и как следствие и 1
как раз для 2, 3 и необходим boost.
вы в проектах ипользуете std::vector, std::string, или свои поделки?
boost::shared_ptr, boost::lexical_cast, boost::function, ... -- все из той же серии.
Надеюсь со временем он займет место аналогичное CPAN, CTAN
E>Да ещё и удорожают разработку, так как не каждый программист затянет применить все эти прелести не слишком разрушительно
E>Собственно содержание моего утверждения такое. Но я так ине понял согласен ты с ним или нет.
Здравствуйте, Erop, Вы писали:
[skipped]
E>Собственно я в выделенном абзаце и утверждаю, что обычно boost, loki, etc портят 3, 2, и как следствие и 1 E>Да ещё и удорожают разработку, так как не каждый программист затянет применить все эти прелести не слишком разрушительно
Ну от некоторых частей буста я тоже в шоке — трудно для понимания, с наскоку не разберешся.
E>Собственно содержание моего утверждения такое. Но я так ине понял согласен ты с ним или нет.
Не совсем.
КЛ>>Всем нравится простой код, а "крутой" еще больше E>А какой код "крутой"? Ты что имеешь в виду? У меня есть подозрение, что "крутой код" мне не нравится.
Здравствуйте, jazzer, Вы писали:
E>>Единственный заметный мне эффект -- разработка требует больше времени, более продвинутых, то есть дорогих, программеров и становиться труднее в отладке и поддержке. А плюсы-то какие? J>сам же и ответил (см. выделенное) J>Разве этого мало?
Ну вообще говоря и как потребитель ПО и всяких устройств, содержащих ПО. И как программист, я заинтересован в обратном
В смысле что как потребителю мне хочется чтобы всё было подешевле и понадёжнее, а как программисту мне хочется решать реально сложные и нужные людям задачи, а не ковыряться с искусственно созданными трудностями
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
КЛ>Ну от некоторых частей буста я тоже в шоке — трудно для понимания, с наскоку не разберешся.
+1
E>>Собственно содержание моего утверждения такое. Но я так ине понял согласен ты с ним или нет.
КЛ>Не совсем.
КЛ>>>Всем нравится простой код, а "крутой" еще больше E>>А какой код "крутой"? Ты что имеешь в виду? У меня есть подозрение, что "крутой код" мне не нравится.
КЛ> Высокотехнологичный, сложный....
КЛ>Но это когда ты его писал , а вот когда не ты
Ну я уже достиг такой победы склероза, что если и я, но не прямо сейчас, то тоже
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
КЛ>Есть иерархия полиморфных объектов, которые отображаются в комбобоксе. При изменении текущего объекта в комбике надо апдейтать UI(кнопочки, радиобаттоны и т.п.). Вот для этой хрени я и заюзал визиторов. Иерархия состоит из 3х(!) классов. И вот из-за них я и замутил все это дело с визиторами. Скажешь зачем, ведь проще было if'ов напихать? Да, проще, но я решил что: КЛ>а) так красивее (просто мне нравится!) КЛ>б) потом если придется добавить 4, 5, 6 класс я пойму, что сделал правильный выбор.
КЛ>НО, у visitors есть свои нехилые недостатки (взаимозависимости) и никто не говорит о том, что это панацея.
Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
Я так понимаю все ваши проблемы от того что вы работаете в команде и ваш код пользуют
другие программеры.
Мне в этом отношении проще — пишу все проекты от начала и до конца , поэтому
грамматику использую по настроению
В принципе предпочитаю raw код — думаю что его проще просматривать и отлаживать
шаблоны пришлось использовать один раз — но я не жалею
Это конечно не подразумевает использования STL или того же CArray из
MFC , (котрый люблю и уважаю (MFC) ), а именно написание своих шаблонов.
Исключения практически не использую — толко коды возврата -NULL для
возврата указателей -1 в основном для другого.
Честно говоря с трудом представляю нынешнее программирование без
использования STL и иже с ним.
И хотя сам предпочитаю raw программирование , и думаю что такого должны придерживаться все
(вчера читал у Майерса чьето высказывание (может его) "Нужно писать просто насколько
возможно ,но не более"(хотя вроде это был Шекспир)) ,но знать все возможные методы
решения задачи никогда не помешает, ибо что для одного raw для другого "огого!!".
Ладно пора работать , а то у меня тут такой чужой код висит, что периодически
забываешь что это вообще может быть программой
Здравствуйте, jazzer, Вы писали:
J>Ну не for_each, а accumulate, copy, merge и т.д. Ты же, надеюсь, не при помощи qsort сортируешь? И мапы вручную не пишешь? J>Практически всегда лучше писать одну строчку, чем 3, и уж тем более чем 30.
accumulate, как мне кажется, не читабельнее чем for, copy тоже.
merge -- уже чем-то лучше, но нужен редко
Мапы и сортировку я использую из конторской библиотеки примитивов. Хотя и qsort ничем таким особенным не плох. Главный недостаток -- непереносим. Например разные реализации qsort (впрочем как и разные реализации stl) по-разному сортируют массив, в котором встречаются равноценные элементы.
J>>>Я к тому, что нельзя с мерками прикладного кода подходить к библиотечному коду. А Александреску выступает именно как разработчик библиотек, и ничего страшного не произойдет, если ты, помимо STL, подключишь Loki, потому что пользоваться ею, насколько я понимаю — не сложнее, чем STL. А вся александресковская сложность — под капотом, ты ее и не увидишь и дела с ней иметь не будешь. Укажешь в параметрах типа, что именно тебе надо — и вперед.
Ну вот мне примеры использования Loki позитивные не известны. Мало того, про "сложность под капотом" я уже писал. Обычно я сижу как раз под этим капотом и пытаюсь понять кто же и что накосячил в клиентском коде, что эту прекрасную и мощную библиотеку так загнуло-заломало?
J>...А со SmartPtr и правильной стратегией это можно автоматизировать и вообще сделать зависимым от режима компиляции (в смысле, #ifdef _NDEBUG), когда в релизе он будет вести себя как голый указатель. J>Но, повторяю, я не пробовал локи вживую вообще, хотя было бы, безусловно, интересно.
Собственно поинт состоит в том, что всё это виликолепие не нужно
Мне вполне хватает трёх умных указателей. Один для COM-объектов, и он не наш, а баблиотечный, один просто scope_guard, с запретом копирования. (На самом деле он бывает векторным и скалярным, но первый мне пока что не пригождался). Првда по историческим причинам он давно очень у нас реализован и им и пользуемся. И ещё один со счётчиком. Он предполагает, что имущество, которым он владеет является public virtual наследником некоего класса, в котором реализован счётчик.
Собственно больше мне ничего от умных указателей ни разу не понадобилось.
Дампить логи, для отладки. Решать нужно ли удалять все элементы коллекции, считать есть ли утечки памяти и т. д. ИМХО надо не в умном указателе, а в специализированных средствах.
В нашей библиотеке, например (так же как и в crt-куче, кстати) есть средства контроля утечек, для проверки всё ли хорошо я традиционно пишу методы IsValid, для записи логов или save'ов использую соответсвующие стредства и не испытываю ни малейшей потребности вставить всю эту нужную и полезную функциональность в какой-нибудь умный указатель
Короче мне кажется, что лучше иметь продуманную библиотеку, простую, и ясную, как в использовании, так и в поддержке и отладке, как клиентского кода, так и кода баблиотеки. А не нереально сложный со всех сторон универсальный всемогутер, который предоставляет два миллиона ненужных возможносетй наряду с пятью из шести нужных.
E>>Ну я пишу простую вещь. Что не придумали ещё задач, которые столь сложны, что их решать проще с помощью Loki, чем без её помощи E>>Вернее задачи может и придумали, но жизнь их пока не просит разрешить J>SmartPtr — достойная задача? Имхо, почти на каждом шагу. SmallObjectAllocator? (Не помню, правда, совместим ли он с STL, если да, было бы вообще здорово — можно было бы рожать всякие std::map<int, double>, не особо боясь за эффективность.)
Ну, на мой взгляд, SmartPtr, SmallObjectAllocator и даже STL и C++ -- это не задачи, а средства. А задача, это например: "разработка автоматической коробки передач, которая не нуждается в более мощном двигателе, чем механическая, при равном комфорте вождения".
Или "Разработка обучающей игры, которая позволяет ненавязчиво и в игровой форме достичь обучаемым детям таких-то и таких-то результатов". Или, даже, (что ближе всего к книжке А., кстати ): "Заработать $100 000 000", но никак не SmartPtr
E>>Мне не нравится парадигма "сделать так сложно, как только можно". E>>Мне нравится парадигма "сделать так просто, как только можно". J>Сам Александреску придерживается того же мнения http://rsdn.ru/Forum/Message.aspx?mid=1850161&only=1
Да я знаю. Я скромно считаю, что мы с ним единомышленники. И что Loki -- это можельная библиотека. Она в оснвоном демонстрирует каких можно приколов напрограммировать на C++, а не как надо писать полезные и хорошие программы
В целом мне интересно было читать, что там такоего прикольного придумал А.
Но мне не прикольно, когда так начнают программировать, и тем более неприкольно, что начинают стримиться к такому стилю те, кто так программировать ещё не умеет
J>так алгоритмы подключаются через #include <algorithm> явно J>Это во-первых, а во-вторых, конкретно к вектору это никакого отношения не имеет, сам знаешь, алгоритмы работают на уровне итераторов (аналог указателей).
Ну может имеет, а может не имеет, а вот итераторы в вектор вкопаны по пояс, хотя мне они занафиг не нужны. Толкьо вредят.
E>>Потому что каждый раз, когда где-то, как правило в каком-то неудачном коде написанным невнимательным новичком, портится память, так я попадаю мордой под этот капот.И вынужден там ковыряться. J>Аналогично и с "голыми" указателями. Но, по моему опыту, неправильное использование голых указателей отследить сложнее.
Нифига не анологично. У нас не пользуются указателями для итерации массивов. У нас пользуются индексами
Мне, кстати, в std::vector еще не нравится, что в operator[] не проверяют границ.
Но память обычно портят как0нибудь вычурно. Например недавно одному программисту нужно было добавить в узлы некоего дерева своё поле. При этом тип узла он менять не мог. Мало того, это поле использовалось для того, чтобы это дерево строить.
Он сделал так. Завёл map из указателей на узлы дерева в эти самые поля. Добавлял эти поля в map по требованию И было ему чсастье, пока при построении дерева он не начал удалять некоторые узлы
map он при этом не чистил, но иногда доставл из него указатели на вершины. Ну и на этом прекрасном пути память и портил.
а проявлялась проблема в другом месте, где другой достойный мужчина использовал stl. Проблема проявлялась на merge. Я довольно долго всё это счастье отлаживал.
E>>И при этом пользы-то никакой от наворотов я не получаю. Получаю гемор, поучаю догую компиляцию, получаю причудливую зависимость от версий компиляторов и библиотек и много чего ещё "хорошего". J>Эту всю радость ты получишь абсолютно с любой библиотекой. Мне, по крайней мере, еще не попадались библиотеки, у которых никогда не было бы проблем при переходе с версии на версию компилятора (не говоря уже о смене компилятора с SunCC на GCC, скажем). И тем масштабнее проблемы, чем больше разница версий. А уж о том, как разные версии разных библиотек друг с другом уживаются — не сыпь соль на рану.
Не зняю. Я наш код много куда переносил. И скажу так, что ИМХО STL переносимость понижает! Причём делает это в плохопредсказуемых местах И это один из его многочисленных недостатков
J>У меня эмпирический закон примерно такой: сложность кода определяется задачей, и только. J>Отсюда простая мораль: использование [правильно спроектированных] сложных вещей должно быть простым.
Ну я согласен, но я немного поправлю: "Оптимальная сложность кода определяется задачей, а не средствами"
Часто есть много путей решения задачи, и обычно они премрно эквиваленты. Но, тем не мненее есть и намного более сложные пути. Вот писать Word на ассемблере заметно сложнее, чем на C++. А писать какую-нибудь тупую вычматематическую задачу, которая вычисляет какие-то формулы в цикле при помощи algorithm сложнее, чем просто на C или C++. Или тебе так не кажется?
J>Чтобы в случае неправильной работы сразу было видно, в чем причина — в библиотеке или в твоем коде (STL в этом смысле, например, не идеал: одна возня с удалениями элементов контейнеров по итераторам чего стоит. Могли бы и предусмотреть сразу чего-нть на эту тему).
Да не вопрос. Пишеш простую программу. О схеме владения объектами в твоей программе не думаешь. Потом получаешь assert'ы и порчу памяти с утечками. И говоришь: "ну ясен пень -- проблема-то в библиотеке!"
Так что ли?
E>>Я ещё раз призываю рассказать где же оно всё бывает нужно-то? J>Ну уже сказал. В "Прикладных вопросах" был топик про реальное использование boost::mpl — посмотри еще там. J>У меня лично сколь-нибудь нетривиальное использование шаблонов в основном сводится к traits, большего сановский компилятор просто не позволяет.
Про mpl я говорить не хочу, так как все известные мне случаи "выгод" от его применения носят чисто идеологический характер. Ну нравится людям так, хотя мне кажется, что так получается сложнее, чем иначе. Но обсуждать тут нечего. Кроме того, это отклонит нас изрядно от обсуждения книжки А.
Я собственно просил рассказть о случае удачного применения loki
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
A>Твоё отношение к сторонним библиотекам крайне отрицательно, тогда как решение использовать ту или иную библиотеку — это просто компромис. В нём есть и за и против. Ты видешь только одно против.
Почему же крайне отрицательно? Отнюдь, когда библиотека облегчает мне работу с предметной областью — то я двумя руками и двумя ногами за. Но тащить тот же boost::singleton к себе в проект ради чистоты концепции — увольте Благо, 90% всех синглтонов можно сделать на коленке описанным способом за 5 минут.
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, minorlogic, Вы писали:
M>>Если я не ошибаюсь , то патерн визитор , полезен в иерархии где изменение базовых классов недопустимо , в вашем случае это было так ? Т.е. действительно нельзя было добавить пару виртуальных функций ?
КЛ>Откуда такая информация? Каких виртуальных функций? КЛ>Упрощенный смысл визитора в том, что он позволяет статически выбирать тип объекта с помощью динамического механизма. Т.е. выбор типа объекта, с которым будем работать, делает сам объект, статически.
Ой как сказал. Я бы не понял, если бы не знал о чем речь . А я вот не использую visitor. Из прынцыпа. Я до сих пор использую двойную диспетчеризацию (в контексте, как она описана здесь), потому как считаю, что полезная содержательная суть визитора — это двойная диспетчеризация. Все остальное — это навороты и от лукавого. И в основном для того, чтобы дотянуть его до "паттерна проектирования". Поправьте меня, если я не прав.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Alex_Avr, Вы писали:
E>>>accumulate, как мне кажется, не читабельнее чем for, copy тоже. E>>>merge -- уже чем-то лучше, но нужен редко E>>>Мапы и сортировку я использую из конторской библиотеки примитивов. A_A>>Код, в котором используется STL более переносим, чем "конторская библиотека", хоть, может быть, и менее удобен для каких-то задач. A_A>>По поводу переносимости кода с использованием STL — ниже.
E>Неправда. У меня есть конкретно довольно большой опыт переноса разного кода под разные платформы. Иногда очень-очень сложного инаогда не очень. Если самописаня библиотека не написана слишком умно, то она конечно же переносимее.
Если библиотека написана написана на чистом C, то она еще более переносимая
Я немного не это имел ввиду. Я хотел сказать, что для STL уже есть реализации для разных платформ, и в случае
необходимости, при использовании этих реализаций можно получить поддержку от ее разработчиков, уже знакомых с конкретной платформой.
В случае конторской библиотеки ее необходимо портировать _самим_, по ходу дела разбираясь с осбенностями и ограничениями очередного компилятора/платформы.
А с выделенным — согласен.
A_A>>Вообще гворя STL — это просто описание в Стандарте некоторых интерфейсов и некоторых требований к их реализации. A_A>>Так что переносимость как таковая зависит от того, кто ее _реализует_. A_A>>Если же требуется действительная переносимость с платформы на платформу, то что мешает использовать A_A>>STLPort (здесь список поддерживаемых компиляторов) A_A>>или SGI STL? E>(за ссылки спасибо, но мимо кассы)
Думаю, что не совсем мимо кассы. Использование одной и той же реализации STL на разных платформах сводит проблемы переносимости к минимуму,
если эта реализация поддерживает все необходимые платформы. Для STLPort список поддерживаемых платформ весьма широк.
E>Заменть реализацию STL обычно что-нибудь мешает. Так что реализация STL обычно навязывается целевой платформой, особенно если ты портишь библиотеку
Для расширения кругозора — можно узнать причины, которые мешают заменить используемую реализацию STL на другую, кроме заточенности
кода на особенности конкретной реализации и своих доработок ее напильником?
E>Про qsort я согласен кроме млочей. E>1) во многих случаях qsort вполне пригоден. Скажем переделывать код заради изведения qsort я стану только если что-то ещё надо
+1
Если код делает то, что требуется, то его из "идеологических" соображений менять не стоит.
E>2) У нас есть своя реализация шаблонной сортировки. Она без многих чудес, сделана из какого-то популярного в CS алгоритма и довольно хорошо работает.
Для вас реализация, отладка и тестирование своего алгоритма сортировки была оправдана, а для кого-то это не так.
E>3) stable_sort, как я понимаю, менее эффективен
Это да, но опять-таки в конкретной ситуации это снижение эффективности может быть абсолютно не значимо. Также как и с qsort
E>Да кривые руки могут всё. Поэтому защищаться от них путём пложения шаблонных монстров ИМХО плохо. E>Проблема в том, что когда кривые руки ломают простую библиотеку, то даже под капотом мне легко, а когда STL -- нет. А задачи-то решаемые простой библиотекой и STL примерно одни и те же.
Насколько я понимаю, в STL шаблоны используются для повышения гибкости, а не для защиты "от дурака".
Те же итераторы используются для того, чтобы сделать реализацию алгоритмов независимой от конкретных контейнеров,
чтобы сортировку или поиск элементов можно было использовать не только для контейнеров STL но и для
обычных массивов в стиле C. Если вам все это не нужно, и есть ваша собственная библиотека — так зачем вам STL?
STL такая, какая есть, потому что нацелена на универсальность использования, а более общее и универсальное решение
всегда сложнее более частного решения.
A_A>>Зато это "великолепие" может быть нужно многим другим разработчикам. E>Ну вот в нашей конторе пока что пригодился ещё векторный scope guard, да и то, ИМХО, со зла
Фор хум хау, как говорится.
E>Я согласен. И некоторые идеи позитивны. Негативен вектор. Когда люди ценят не как проще, а как круче, гибче дуракозащищённее и т. д. E>Когда "сложность под капотом" не считают недостатком. И уж тем более хуже когда недостатком не считают просто сложгность. Типа говорят "ну и что что сложно, а мы модульный тест навернём и будет так же надёжно"
Использование той или иной библиотеки — как тут правильно кто-то заметил — всегда компромисс, всегда есть свои плюсы и минусы.
И тут уж надо рассматривать конкретную ситуацию, конкретные требования и условия, в частности и опыт ее использования имеющимися в наличии программистами.
Эта самая "сложность" может быть оправданна в каких-то случаях, а в каких-то абсолютно не нужна.
Я согласен с тобой в том, что при прочих равных условиях я предпочту более простое решение, как более надежное
и более легкое в сопровождении.
A_A>>Но при реализации больших проектов возможность расширения/развития/добавления функциональности тоже является A_A>>немаловажной частью этой самой задачи. И здесь решения с "наворотами", но более гибкие, могут быть A_A>>предпочтительнее "простого" кода. Опять же, все зависит от конкретной ситуации. E>Что-то я вот не пойму, как поддержка итераторов в STL скажем добавляет гибкости и возможностей развития в код автоматической коробки передач? ИМХО
всё это счастье добавляет хорошо продуманная архитектура проекта.
Ну это ты уже утрируешь. Выше я писал о том, для чего нужны итераторы.
E>А многим неопытным инженерам кажется, что намного важнее применить какой-то сверхумный и сверхгибкий указатель, да ещё проследить, чтобы не было goto
Понимание многих вещей приходит только с опытом.
A_A>>Может просто не использовать эти лишние для вас особенности? Например с стандартах кодирования явно запретить использовать все, A_A>>что связано с итераторами. E>Да "под капотом" они всё равно останутся
Так и из Стандарта они никуда не денутся. Единственный выход — не использовать STL вообще
и писать свои библиотеки или использовать другие подходящие для ваших требований, тот же Roguе Wave,
например.
E>>>Мне, кстати, в std::vector еще не нравится, что в operator[] не проверяют границ. A_A>>Да, в operator[] нет проверки допустимости индекса, чтобы его могли использовать A_A>>без потери производительности те, кому эта проверка не нужна. Кому проверка нужна A_A>>могут использовать std::vector::at () вместо std::vector::operator[](). A_A>>В лучае выхода индекса за допустимы границы at() бросает исключение. E>Да знаю я STL
Верю!
E>Я говорю, что мне там не нравится. Я бы предпочёл иметь метод fast_get_at, для тех кому проверка не нужна. E>Просто STL контейнеры оптимизированы под некоторый стиль кодирования. С итераторами, функторами, алгоритмами и т. д. E>Поэтому-то им проверки и не нужны. Ты в клиентском коде почти не должен лазить в вектора непосредственно. E>А алгоритмы типа отлажены. E>А мне вся эта парадигма гажется неоправданно переусложнённой, так что я с радостью выбросил бы и итераторы и отсутсвие проверок в самом частотном доступе к элементу и т. д. E>Реально для этакого "опрощённого" кодирования, STL хорошо бы проредить и передезайнить.
Можно предложить свои классы в качестве дополнения в следующий Стандарт С++
E>Ну boost очень разнороден. Содержит и дельные вещи, но навороты ИМХО всё время не по делу.
И не для любого компилятора.
E>Ну а STL, как я уже писал не под то немного заточен. Всё-таки он несколько более sofisticated, чем хотелось бы. E>Ну а Loki, ИМХО, неприменима. Хотя и на оригинальном Pascal люди проекты рожали, хотя тоже учебный язык вроде как был поначалу
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Erop, Вы писали:
КЛ>>>6) Шаблон Visitor (к своему сожалению юзаю в 1ом месте, а ты? Пременимость — пр. пункт) E>>Почему к сожалению и о чём именно ты сожалеешь? О том, что используешь или о том, что используешь один раз? E>>Мне известно о четырёх серъёзных попытках использовать этот шаблон. Все четыре провалились. То есть потом код был всё-таки переписан, без визитора и стал проще, лучше, понятнее и всё такое.
J>Вот здесь присоединяюсь. J>На мой взгляд, этот паттерн — один из самых неудачных.
Неудачных паттернов не бывает. У всех у них есть свои недостатки и преимущества. Неудачным бывает место его применения. К тому же, там все просто до ужаса, в чем там можно запутаться? Ну да ладно, вам виднее.
Здравствуйте, remark, Вы писали:
R>Как бы то ни было, паттерны тоже не применяем, т.к. не все же студенты знакомы с ними. Ну оканчивается название класса на Visitor. Ну и что? Кому-то это ничего не скажет. R>Так что 20 функций из С и ни фичей больше
Это всё крайности, а я за взвешенность и умеренность выступаю
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
E>>>Но на практичке я постоянно встречаю людей, которые применяют налево и направо навороты, и совсем не встречаю, таких, которые пишут плохо, потому что наворотов от Александреску не применили R>>Повезло E>А ты часто встречал людей, которые написали плохой код именно потому, что не применили идеи А? E>Опиши как это было-то?
Пожалуйста.
1. Видел в проекте (благо не в моём) самопальный умный указатель — зрелище достаточно убогое. Часть состояния открытая. Не защищён от большинства неправильных использований. Не обеспечивает безопасноть относительно возникновения ошибок. И т.д.
2. Видел много примеров плохого дизайна, когда люди не разделял ортоганальные аспекты. А валили всё в одну большую кучу.
Дело не именно в А. Дело в том, что люди пытались делать все очень просто, как в лабораторной в институте. Я бы даже сказал наивно. Со временем это аукалось.
E>>>Ну на самом деле задачи просто проще методов Александреску. Увы, такая вот жизнь вокруг меня. Хотя программы в целом непростые, так скажем. И программисты квалифицированные. R>>Смотря какие подразумевать критерии хорошего решения задачи? E>Успешные многолетние проекты. С большим числом версий, миллионами инсталляций по миру. Поддержка, развите. Очень сложные задачи в смысле того, что не очевидно как это реализовывать вообще, сложные пользовательсткие интерфейсы и т. д. E>Есть, в том числе, и программы, являющимися лучшими или одними из лучших в мире в своих сегментах. R>>Если только наличие требуемого поведения, то тогда конечно любую задачу можно решить очень просто... E>Сопровождение и развитие ещё требуется.
Сопровождение и развитие — это относится к проекту, а касательно кода? Т.е. какие требования к коду, что бы проект был сопровождаемым и развиваемым?
Здравствуйте, remark, Вы писали:
A_A>>>Поэтому нужен баланс между простотой и универсальностью решения. E>>Конечно, просто мне кажется, что в STL баланс неоправданно смещён в сторону универсальности. Вот, скажем, в каких языках было нужно реализовывать алгоритм merge в библиотеке?
R>А какие ещё языки предназначены для создания библиотек?
Ну, скажем дельфи
Но вообще библиотек я знаю вообще много на каких языках. Скажем на fortran.
А вот стандартная библиотека, или какое-то её подобие есть вообще практически во всех языках
А merge я вот что-то не припомню. Видимо не было на него пока что спроса всё-таки
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
A_A>>>>Поэтому нужен баланс между простотой и универсальностью решения. E>>>Конечно, просто мне кажется, что в STL баланс неоправданно смещён в сторону универсальности. Вот, скажем, в каких языках было нужно реализовывать алгоритм merge в библиотеке?
R>>А какие ещё языки предназначены для создания библиотек?
E>Ну, скажем дельфи
Нет
E>Но вообще библиотек я знаю вообще много на каких языках. Скажем на fortran. E>А вот стандартная библиотека, или какое-то её подобие есть вообще практически во всех языках
Отношения к делу не имеет. В прикладном языке и стандартная библиотека соответствующая.
E>А merge я вот что-то не припомню. Видимо не было на него пока что спроса всё-таки
Это языки совсем другие.
Твоя цитата:
так что я с радостью выбросил бы и итераторы и отсутсвие проверок в самом частотном доступе к элементу и т. д.
Советую почитать Страуструпа про язык с++. Ты сейчас предложил примерно следующее "А давай в java введём ассемблерные вставки".
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>1. Видел в проекте (благо не в моём) самопальный умный указатель — зрелище достаточно убогое. Часть состояния открытая. Не защищён от большинства неправильных использований. Не обеспечивает безопасноть относительно возникновения ошибок. И т.д.
E>Согласен, но мне кажется, что часть таких ошибок некритична, (скажем защита от плохого использования не всегда нужна),
Ну да, если работы уже мало. То что бы не уволили надо писать код с ошибками, что бы потом было что делать
Или как ты сам говорил, если цель программиста сорвать проект, то тоже, конечно можно не защищать от неправильного использования.
E>а часть происходит от общей низкой квалификации. Но в любом случае умный указатель -- это довольно древняя идея. И мне кажется, что она не идея А. Во всяком случае есть много реализаций умных указателей, которые вовсе не являются продвинутыми шаблонами.
Зато они не позволяют за 5 минут поменять какой-то аспект программы.
Ты спрашивал про опыт использования Loki — недавно воспользовался бонусом Loki — написав 10 строк кода и потратив 10 минут, изменил способ shedul'ирования всех синглтонов на разрешение. При этом написал именно то, что требовалось семантически — стратегию shedul'ирования на разрушение. При этом не было ни одной ошибки. При этом поменялось всё сразу и везде, без нудного поиска всех мест и вспоминания при запуске "ах, да ещё здесь забыл поменять".При этом не надо было затрагивать другие аспекты программы.
R>>2. Видел много примеров плохого дизайна, когда люди не разделял ортоганальные аспекты. А валили всё в одну большую кучу. E>Плохого дизайна я видел часто много. Но вот именно от того, что они не применили Loki я что-то ещё не разу не пожалел
Именно применение Loki не обязательно.
R>>Сопровождение и развитие — это относится к проекту, а касательно кода? Т.е. какие требования к коду, что бы проект был сопровождаемым и развиваемым? E>Это отдельная долгая тема. В целом можно рассматривать такое свойство кода, как сопровождаемость и возможность переиспользования. E>Ну типа сколько в среднем занимает что-то сделать с кодом. Чем сумма меньше, тем сопровождаемость больше
Именно для этого и были придуманы шаблоны. Советую догонть время, а не считать до сих пор на счётах.
Здравствуйте, remark, Вы писали:
E>>Согласен, но мне кажется, что часть таких ошибок некритична, (скажем защита от плохого использования не всегда нужна), R>Ну да, если работы уже мало. То что бы не уволили надо писать код с ошибками, что бы потом было что делать R>Или как ты сам говорил, если цель программиста сорвать проект, то тоже, конечно можно не защищать от неправильного использования.
Ну защита от неправильного использования нужна, ИМХО, только если кто-то так реально ошибается.
Пртсто часто так выходит, что вреда от "защиты от всех мыслемых возможных проблем" намного больше, чем пользы
R>Зато они не позволяют за 5 минут поменять какой-то аспект программы. R>Ты спрашивал про опыт использования Loki — недавно воспользовался бонусом Loki — написав 10 строк кода и потратив 10 минут, изменил способ shedul'ирования всех синглтонов на разрешение. При этом написал именно то, что требовалось семантически — стратегию shedul'ирования на разрушение. При этом не было ни одной ошибки. При этом поменялось всё сразу и везде, без нудного поиска всех мест и вспоминания при запуске "ах, да ещё здесь забыл поменять".При этом не надо было затрагивать другие аспекты программы.
Опять же, ИМХО, в нормально спроектированной системе это вообще не нужно делать! В этом собственно состоит основная идея моего сообщения. Что проблемы, которые решаются таким способом, на самом деле не актуальные. И возникают обычно из-за переусложнённого или просто неверного дизайна
R>>>Сопровождение и развитие — это относится к проекту, а касательно кода? Т.е. какие требования к коду, что бы проект был сопровождаемым и развиваемым? E>>Это отдельная долгая тема. В целом можно рассматривать такое свойство кода, как сопровождаемость и возможность переиспользования. E>>Ну типа сколько в среднем занимает что-то сделать с кодом. Чем сумма меньше, тем сопровождаемость больше
R>Именно для этого и были придуманы шаблоны. Советую догонть время, а не считать до сих пор на счётах.
За совет спасибо, хотя он и кажется мне немного хамским , но я таки верю, что ты это из добрых чувств написал.
Но в целом для чего кем-то были придуманы шаблоны -- проблема его биографии. Тем более, что, скажем, STL, ИМХО, был придуман в основном из соображений "гибкости" и "красоты". На мой взгляд оба критерия обычно контрпродуктивные. Во всяком случае с сопровождаемостью напрямую никак не связанные
Для нас важно что же выходит, когда продвинутые шаблоны применяют на практике.
Вот ещё раз напишу тебе, что ни разу ещё не встретил случая, чтобы писанный по месту шаблон потом смогли без весьма продвинутого гемора переиспользовать
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
FF>Как подобную задачу решают у вас без приминения оных "изысков"?
Делают абстрактный класс (интерфейс). Подписчики должны его реализовывать. Не самое страшное требование, ИМХО.
Здравствуйте, Left2, Вы писали:
L>Делают абстрактный класс (интерфейс). Подписчики должны его реализовывать. Не самое страшное требование, ИМХО.
Ок. Тогда конкретнее. Возьмем типичный пример — форма и набор контролов. Контролы уведомляют форму о происходящих в них событиях. Кнопка — вызовом метода void OnClick(), editbox — void OnTextChange(const char* newText), listbox — void OnSelChange(int oldItem, int newItem);
Правильно ли я понимаю вашу логику, что для каждого варианта такого вызова надо делать отдельный интерфейс? А в форме — все их реализовывать? А что мне делать, если на форме несколько кнопок, несколько полей ввода и списков, и для каждого такого контрола должен быть свой обработчик? Это первый момент. Второй — такой подход накладывает некоторые ограничения. А именно:
— В качестве обработчиков я не могу передавать свободные функции.
— Обработчиком может быть только метод полиморфного класса.
— Я обязан унаследовать класс-обработчик от заданного интерфейса.
Не умножай количества сущностей сверх необходимого
КЛ>Почти. Есть комбик для выбора текущего айтэма. Есть 2 кнопки, которые грэются в зависимости от него. Есть группа радиобаттонов, которые тоже могут грэиться. Есть листвью. В общем, все контролы общие, и я даже не думал делать это через ps. Кроме того, как ты стал бы выбирать, какой ps показывать? Опять же, либо if'ы, либо vf'ы, либо visitors. Надеюсь, теперь понятно?
Я за то, что говорит Erop. Александреску полезно почитать, но код должен быть настолько простым, насколько это возможно. Основываясь на сказанном здесь
, я бы в базовом классе создал [чисто] виртуальную функцию которая бы вызывалась при выборе текущего айтема и отвечала за установку состояния контролов. Ну а классы-потомки бы переопределяли ее как им нужно.
Здравствуйте, qqqqq, Вы писали:
E>>Если программист стал незамениным, его пора увольнять (с) не помню кто Q>Это теоретики... Ни разу не видел ничего подобного. Задача тимлида проследить за необходимостью "навороченности" кода и дизайна.
А я это видел в 4 фирмах и десятке продуктов. В одном из случаев из я лично был таким незаменимым (уволился сам). В мелких фирмах всегда так. А крупные — это майкрософт с ораклом, да и там не всё с этим в порядке, по некоторым признакам. Тимлидами всегда были блатные, во первых просто бездельники, а во вторых — абсолютно безграмотные — при всём своём желании не в силах понять что там делают кодеры — языка-то не знают, ОС не знают, программирования не знают, всё больше про паттерны болтают — благо не особо трудно и нет компилятора, который бы их "творения" оценил по справедливости.
А там где тимлид с головой (бывает, хотя и редко) — он и есть незаменимый.
Здравствуйте, remark, Вы писали:
R>А есть программисты, которые сразу считают for_each — сакс, я его ни разу не применял, но всё равно это сакс.
Тот for_each который в STL — тот сакс, ибо писать функтор для каждого чиха неудобно
BOOST_FOREACH гораздо удобнее
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>Грубо говоря, если тебе нужно нечто вроде for_each(v, v+size, mem_fun_ptr), то если у тебя нет под рукой STL — ты напишешь цикл и не будешь париться, а если под рукой есть STL — ты заюзаешь for_each. Но несмотря на все преимущества for_each, если у тебя нет STL, то ради одного for_each городить всю многофайловую инфраструктуру из iterator, algorithm, functional и т.д. несколько неумно. Но если оно уже есть — почему бы этим не воспользоваться? E>Я вот не особо понимаю что же за преимущества у for_each? Мне for в данном конкретном случае и понятнее и приятнее и если не дай божи чего не работате, меня не утянет "под капот" откуда я может и не вынырну без помощи более опытного товарища
J>>Я к тому, что нельзя с мерками прикладного кода подходить к библиотечному коду. А Александреску выступает именно как разработчик библиотек, и ничего страшного не произойдет, если ты, помимо STL, подключишь Loki, потому что пользоваться ею, насколько я понимаю — не сложнее, чем STL. А вся александресковская сложность — под капотом, ты ее и не увидишь и дела с ней иметь не будешь. Укажешь в параметрах типа, что именно тебе надо — и вперед.
E>Ну вот мне не известно удачных случаев применения библиотеки Loki. В сложном коде, в простом, в очень сложном. Короче в любом. E>Мало того, я сильно подозреваю, что их никто не сможет привести. E>Хотя мне известны попытки. Все в конце концов неудачные. Как на уровне использования Loki, так и на уровне использования идей А.
J>>А то, что ты пишешь про прикладной код — это все правильно и я с этим полностью согласен. E>Ну я пишу простую вещь. Что не придумали ещё задач, которые столь сложны, что их решать проще с помощью Loki, чем без её помощи E>Вернее задачи может и придумали, но жизнь их пока не просит разрешить
E>Мне не нравится парадигма "сделать так сложно, как только можно". E>Мне нравится парадигма "сделать так просто, как только можно". E>Понятно что слишком просто делать дорого. Но всё-таки стремиться надо к простоте, а не к сложности. E>Если, например, у тебя протая программа, которая интегрирует 20 COM-объектов между собой, то напиши её на VB или на C# и не парь себе мозг без нужды с Comet
. E>Понятно, что если у тебя сложный проект, который ещё к тому же и 100 COM-объектов интегрирует и сам много чего нетривильного делает и почему-то никак не удобно все мозги засунуть в 101-й COM-объект, а менеджер этого барахла забомбить таки на VB, то тогда конечно проще будет с наворотами. Но это только тогда и только если действительно проще не сделать. А не всегда, когда есть такая возможность, раз уж мы научились писать такие решения не слишком задорого.
E>При этом соображения о том, что "все сложности под капотом" не многое тут меняет. Потому что эти все сложности с нами. Мне и std::vector не нравится потому, что он заради довольно простой функциональности, рожает нереально много всяких сложных довесочков. И от них нельзя просто отказаться. E>Я бы, например, предпочёл, чтобы возможность использования алгоритмов подключалась в stl по явному требованию. А не была намертво в него вцементирована всегда. Почему? Потому что каждый раз, когда где-то, как правило в каком-то неудачном коде написанным невнимательным новичком, портится память, так я попадаю мордой под этот капот.И вынужден там ковыряться. И при этом пользы-то никакой от наворотов я не получаю. Получаю гемор, поучаю догую компиляцию, получаю причудливую зависимость от версий компиляторов и библиотек и много чего ещё "хорошего". А вот реально хорошего от этой всей сложности получаю мало. Потому что все "выгоды", заради которых всё так непросто, они мне не нужны. И я не думаю, что потому, что я учавствую в разработке слилшком простых программ.
E>Я ещё раз призываю рассказать где же оно всё бывает нужно-то?
Было несколько некрофилов , компания egartech.ru
Люди восприняли проект как свою личную песочницу и поюзали всю мощь Loki до какой смогли добраться.
А там где Loki не хватило или там где имена были слишком длинныим обильно склеили соплями макросов.
Использовать макросы они стеснялись не больше чем Loki, я даже подозреваю что они их ЛЮБИЛИ
Сомневаюсь что кто-то может представить ЧТО получилось ЭТО надо видеть.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Erop, Вы писали:
А>Подписываюсь. Читая книжку подумал "здорово, черт возьми". Потом подумал ещё, получилось "ну и на кой черт всё это надо?". Особенно мне нравится метапрограммирование с темплейтами: часок компилируем, отлаживать невозможно, ежели где запятую забыть — компилятор либо помрёт с internal error либо следующюю неделю можно посвятить чтению его ругани. Зато вычислим факториал во время компиляции — добрую тысячу тактов в рантайме наэкономим — может лучше константу на калькуляторе посчитать? Головоломки придумываем или всё же работаем?
Дык не для этого все это писалось... Не для практики... А для защиты диссера...
Понимать нужно... Что у чела — цель другая... Диссер защитить...
А>Выбирайте самое простое из всех возможных решений.
В практическом программировании — безусловно!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Аноним, Вы писали:
А>Давно программируете? Что-то выглядит всё это так, как будто вы вчера про исключения и шаблоны узнали и преисполнились чувства собственного достоинства.
Достаточно для того, что бы писать то, что я пишу.
А>Исключения никак не относятся к самым сложным вещам из тех, которые должен знать профпригодный програмер.
Я и не утверждал обратного. Я считаю, что исключения просто относятся к тем вещам, которые "должен знать профпригодный програмер".
А>Шаблоны как таковые тоже не ахти какая премудрость с точки зрения их использования, хотя и предоставляют извращенцам широкое поле деятельности. Заставь дурака богу молится ...
Если говорить о конкретных вещах/технологиях/библиотеках и т.д. То я считаю, что для человека с головой и способного для обучения вообще есть очень мало действительно сложных вещей.
При желании и наличии времени практически любую вещь можно изучить без особых сложностей. Различие в том, что можно желать и изучать что-то, а можно просто научится пользоваться на минимальном уровне и далее остановится.
А>Что значит "механизм распространения и перехвата исключений" — средства ОС + их использование компилятором? Как это выглядит в ассемблере? Уверен, если того же Александреску спросить о том как реализован "механизм распространения и перехвата исключений" в Win и Visual C++ — вряд ли он детально знает, да оно и не надо (хотя и не мешат). Важно что этот механизм работает так, как того требует спецификация языка, а как он это делает — не так уж и важно.
Зря ты такого мнения о Александреску. Он не только книжки пишет.
Хотя бы надо знать "как того требует спецификация языка". Многие не знают и этого. Вот что именно я подразумевал под "механизм распространения и перехвата исключений". Различные важные детали. Почему исключения надо ловить по ссылке. Почему кидать по значению. Что можно сделать в try блоке функции. Почему нельзя допускать вылета исключений из деструктора. И т.д. Тонких моментов много.
По поводу реализации на уровне ОС/компилятора. В принципе, это можно и не знать. Но. На то мы и с++ программисты, а не java программисты. Для java программиста, например, совсем не обязательно знать что такое стек и как на нём располагаются различные объекты. Или как изнутри выглядят их объектные сслыки. Или что такое указатель. Они и так вполне хорошо и быстро могут делать приложения определённого класса. С++ программист, я лично считаю, должен знать что такое стек, указатель, адрес возврата и т.д. Далее для себя каждый уже может решать лично хочет ли он знать эти вещи или нет.
Здравствуйте, remark, Вы писали:
R>У нас тоже был один препод, который любил считать "так, значит у списка в этом случае вычислительная сложность будет O(1), значит используем список", эх, профайлер бы ему в руки
Кстати, не так уж он был направ — зависит от требований к масштабируемости, imho
Здравствуйте, ArtemGorikov, Вы писали:
AG>Здравствуйте, Аноним, Вы писали:
AG>Супер! А то развели истерию- паттерны, шаблоны проектирования, мы крутые раз можем писать шаблонный код и имеем "шаблонное" мышление. А задачи для школьников 6-го класса (математического) никто решить не может. Реально сложные вещи- алгоритмы и логические задачи. В С++ и шаблонах/паттернах/whatever ничего сложного нет.
Какой ты предлагаешь сделать вывод из сказанного тобой? Что одно нужно, а другое нет? Что надо учить алгоритмы, а паттерны нафиг? Боюсь свести беседу к банальностям, но тем не менее: алгоритмы — средство решения сложных вычислительных задач, а паттерны — средство локализации процесса решения сложных задач. Написать расширяемую, легко поддерживаемую систему на одних алгоритмах не получится.
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, Alex Alexandrov, Вы писали:
AA>Какой ты предлагаешь сделать вывод из сказанного тобой? Что одно нужно, а другое нет? Что надо учить алгоритмы, а паттерны нафиг? Боюсь свести беседу к банальностям, но тем не менее: алгоритмы — средство решения сложных вычислительных задач, а паттерны — средство локализации процесса решения сложных задач. Написать расширяемую, легко поддерживаемую систему на одних алгоритмах не получится.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, srggal, Вы писали:
S>ЗЫ Естественно, можно и глобальный объект сделать как PIMPL с IMPL, создающимся по требованию, но это уже Синглетон , хотя в паттернах нет явных границ, так что как хотите так и называйте.
А зачем это всё нужно?
Если речь идёт о объекте который создаётся где-то по ходу работы программы, то не ясно зачем такие громкие слова и какие-то хитрые паттерны.
А если речь идёт о создании статических объектов (обычно эта тема оказывается рядом с синглетонами ), то ИМХО от этого один только вред
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, creatman, Вы писали:
C>>Поправка: не у Саттера а у Майерса (Наиболее эффективное использование C++). Там как раз раскрывается тема коллизии динамических объектов в компьютерных играх. На сколько мне не изменяет память, Александресску ссылался в своих мульти методах на Майерса и от себя добавлю, что А привел более удачное решение проблемы.
E>Типа для выбора обработчика столконовения? E>Что будет, если пуля типа 8 попадает в монстра типа 13?
Ага для этого.
E>В принципе я соглачен, что там мультиметоды могут быть уместны. E>Правда у меня в анологичной задаче (правда не из области игрушек ) было не совсем так. E>Было так, что есть пара типовых реакций. И есть ещё штуки три нетиповых. E>Соответсвенно хорошо получается с двойной диспечеризацией, что довольно похоже на мультиметоды, в принципе, но и с if'ами в таком раскладе всё выгляди т не особо плохо.
Ну если мне не изменяет память Александресску обозначил двойную диспечерезацию как частный случай мультиметодов. Конечно в личном опыте не приходилось делать тройную и более диспечерезацию, но возможно в каких-то научных областях это могло бы пригодиться. Например можно пофантазировать на тему, как написать симулятор столкновения частиц в ядерном реакторе. Какие архитектурные решения можно тут применить и на сколько оправданно можно использовать мультиметоды Александресску
E>Скажем в моей задаче, если продолжать аналогию, большинство монстров реагирует на столкновене с пулей одинаково, есть один монстр, который на пулю № 7 реагирует особо и есть одна пуля № 12, которая совсем иначе сталкивается с каждым из монстров.
E>Ну и соответсвенно в обработчике стокновения с пулей № 7 стоит if на тип монстра, и специальная обработка на эту тему, и в обработчике столкновения с пулей № 12 стоит двойная диспечерезация (у монстра вызывают метод ProcessBullet12 )
E>Смысл в том, что все обработчики просто ищутся. Всё, что нужно знать про эту конструкцию, это то, что столкновение обрабатывает пуля.
E>Хотя, конечно, и мультиметоды тут были бы более или менее уместны, просто слегка сложнее бы всё смотрелось. E>Если бы, скажем, пуль, вроде пули №12 было бы побольше, то я бы, пожалуй и не спорил. Но вот такой задачи так и не возникло
E>(На самом деле задача совсем другая, чем игры. Типа процесс сопоставления одной из можеделей из списка с разными объектами. Некий перебор AI-гипотез, короче говоря)
У меня задача была более менее тривиальная для игрового разработчика: написать обработчик коллизий в космическом 3D шутере. Почитал Мейрса на эту тему, но ксожалению у него конкретного решения не было (был только анализ различных подходов в том числе и с использованием if else), потом наткнулся на мультиметоды Александресску, который предложил вполне готовое решение и самый большой плюс в том, что была готовая реализация в Loki
Чем мне понравился подход Александресску, так это его простотой, что может показаться странным на первый взгляд
.... E>Собственно поинт состоит в том, что всё это виликолепие не нужно E>Мне вполне хватает трёх умных указателей. Один для COM-объектов, и он не наш, а баблиотечный, один просто scope_guard, с запретом копирования. (На самом деле он бывает векторным и скалярным, но первый мне пока что не пригождался). Првда по историческим причинам он давно очень у нас реализован и им и пользуемся. И ещё один со счётчиком. Он предполагает, что имущество, которым он владеет является public virtual наследником некоего класса, в котором реализован счётчик. E>Собственно больше мне ничего от умных указателей ни разу не понадобилось.
Между прочим если вы внимательно почитаете А. то в начале главы про смарт поинтеры есть мааленькая сноска. Там говориться , если есть возможность поместить счетчик в объект — это НЕОБХОДИМО сделатьи не париться ... а дальше все про СП идет речь о классах которые мы не проектировали. Жаль что многие не читают об этом.
Здравствуйте, minorlogic, Вы писали:
M>Между прочим если вы внимательно почитаете А. то в начале главы про смарт поинтеры есть мааленькая сноска. Там говориться , если есть возможность поместить счетчик в объект — это НЕОБХОДИМО сделатьи не париться ... а дальше все про СП идет речь о классах которые мы не проектировали. Жаль что многие не читают об этом.
Я вот собственно про ТОЖЕ САМОЕ!
Я собственно позитивно к книжке А. отношусь. Я негативно отношусь, если эту книжку начинают применять, так как обычно она не нужна
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Erop, Вы писали:
E>>Здравствуйте, remark, Вы писали:
R>>>Вот это как раз и называется стратегиями (политиками, аспектами), о которых пишет Александреску. R>>>Сторонники "старых и простых" технологий предпочитают создавать в этом случае 50 классов с помощью множественного наследования или более "продвинутые" используют макросы.
E>>Не, Александреску обычно пишет о навёрнутых конструкциях их шаблонов. А я написал о структуре из нескольких указателей на интерфейсы.
R>"Навёрнутые" или не "навёрнутые" — это субъективное мнение. Мне сейчас это не кажется навёрнутым. Просто другая форма записи тем же самых вещей. Не вижу никакой принципиальной разницы между включением нескольких указателей на динамические интерфейсы или включением нескольких указателей на статические интерффейсы. Синтаксис немного другой. Да, у шаблонов синтаксис порядочно сложнее, с этим согласен. Вначале снепривычки было сложно, но сейчас практически одинаково.
R>
Разница огромная в простоте чтения , а значит сопровождения и отладки.
Мы же знаем что шаблоны в С++.
1. Гадко реализованны с точки зрения синтаксиса.
2. Не задают интерфейс который будет использоваться в шпблоне.
Два этих момента снижают читаемость в разы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Как нужно сейчас программировать на C++ ?
От:
Аноним
Дата:
14.04.06 19:42
Оценка:
Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр.
Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень . А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Говорят что хорошая вещь: Large Scale C++ Software но я сам не читал, усиленно ищу
А вообще, смотри в чём проблемы, если в синтаксисе то почитай сначала Страуструпов всяких, Майерсов, Саттеров... Если в самой парадигме то тут тебе может помочь Буч, GoF.
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
Эта книга помимо всего прочего обсуждает реализацию design patterns на C++. Поэтому для начала тебе неплохо было бы ознакомиться с самими паттернами. Возьми книгу "Design Patterns".
А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Книг много. Всё зависит, от того, что ты считаешь традиционным С/С++ программированием.
Здравствуйте, igna, Вы писали:
E>>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.
I>И в большинстве случаев лучше на Java, а не на C++.
Ну в целом я согласен, хотя не согласен, что именно на Java
Обычно в каждой области есть какой-то подходящий язык или языки, которым и стоит пользоваться.
Другое дело, что если контора пишет всё на C++ и C#, то не стоит ради какой-то небольшой задачи заводить ещё и культуру разработки на Java, или там на дельфи. Но в целом подход верный
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Зачастую есть такая тема. Иногда себя на этом ловлю. Но. R>1. Александреску, по-моему, этого не делает, но Саттер вначале каждой книги пишет, что голова должна быть превыше всего, что всё о чём он пишет не должно заменять здравого смысла. Человек-разумный должен это понимать.
R>Т.ч. я считаю, что такой "наезд" на Современное проектирование не обоснован. Эти же мысли можно применить ко всему, он тут ни при чём.
Ну тут форум инженеров-программистов. И стоит всех предостиречь от бездумного увлечения наворотами
Я собственно отвечал автору топика
А что касается примера с поведениями, то от чего бы поведение не задавать парой интерфейсов?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Вот это как раз и называется стратегиями (политиками, аспектами), о которых пишет Александреску. R>Сторонники "старых и простых" технологий предпочитают создавать в этом случае 50 классов с помощью множественного наследования или более "продвинутые" используют макросы.
Не, Александреску обычно пишет о навёрнутых конструкциях их шаблонов. А я написал о структуре из нескольких указателей на интерфейсы.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>"Навёрнутые" или не "навёрнутые" — это субъективное мнение. Мне сейчас это не кажется навёрнутым. Просто другая форма записи тем же самых вещей. Не вижу никакой принципиальной разницы между включением нескольких указателей на динамические интерфейсы или включением нескольких указателей на статические интерффейсы. Синтаксис немного другой. Да, у шаблонов синтаксис порядочно сложнее, с этим согласен. Вначале снепривычки было сложно, но сейчас практически одинаково.
У шаблонов есть много "преимуществ"
1) Намного хуже, чем в случае интерфейсов заданы правила использования. В результате грамотный шаблон написать труднее (больше надо всегопредусмотреть), и воспользоваться труднее (надо выбрать из большего числа мыслемыз альтернативных способов использования)
2) Намного более сложный синтаксис и семантика. Вот, например, что тут написано:
template<typename TLog>
class Base {
protected
void exit( int );
};
template<typename TLog>
class MyExitProicessor : public Base<TLog> {
public:
void OnExit( TLog& log, int code )
{
LogExit( log, code ); // это какой-то метод MyExitProicessor, описанный ниже
exit( code );
}
};
3) Очень неудобные сообщения об ошибках в пользовательском коде.
А вот реальные приимущества всех этих трюков Александреску они в чём?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял,
Да, такие книжки прочищают мозги хорошо Ж)
Если сам вздумаешь писать тип трэйты, то ты не думай что если даже они будут работать, то всё будет пучком... Такие чтуки реально тормозят компиляцию, у меня к примеру каждый толстый cpp компилируется по 10 сек под P4-2400 на 2003 студии, вот так то. Поэтому написать действительно хорошие тип трейты стоит не малых усилий..
А что касается библиотеки Loki, то там не всё работает..
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, qqqqq, Вы писали:
Q><...>Но если тайная цель все под себя подмять в такой разнородной команаде то да, надо напихать в программу побольше патернов, темплейтов из этой и других подобных книг, замешать с STL, Loki, boost и АСЕ, и еще написать описание соответствено — цены тебе не будет...
Если программист стал незамениным, его пора увольнять (с) не помню кто
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Erop пишет: > Q><...>Но если тайная цель все под себя подмять в такой разнородной команаде то да, надо напихать в программу побольше патернов, темплейтов из этой и других подобных книг, замешать с STL, Loki, boost и АСЕ, и еще написать описание соответствено — цены тебе не будет... > Если программист стал незамениным, его пора увольнять (с) не помню кто
Глупо.
Если ..., то пора увольнять ПМ'а , такое вот ИМХО.
Здравствуйте, alexeiz, Вы писали:
A>А вообще, книга описывает основные паттерны проектирования, которые нужно уже давно знать и использовать самому. Нельзя изучать паттерны по книге Александреску. Нужно прочитать Gang of Four и попробовать делать так как там написано. А потом, когда надоест писать горы однотипного кода и появиться желание как-то автоматизировать этот процесс, то тут приходят на помощь идеи Александреску.
A>Если ты не используешь паттерны. Александреску тебе ничего не даёт, а просто сотрясает воздух в пустую.
Я бы так сказал, что про паттерны можно поговорить особо.
Вообще есть некоторое кол-во паттернов, действительно полезных и попадающихся в реальности.
Но большинство из них -- ИМХО вещь в себе, возникшая от необходимости двишать науку, а не из практических соображений.
Ну а Александреску -- это уже пожалуй вторая производная.
А вообще интересно, почему тебе кажется, что скорее LISP, а не Prolog?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет
Ээ, простите, а где там пролог?
Ленивый, чисто функциональный язык есть, но вот пролог
Здравствуйте, Аноним, Вы писали:
E>>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет
А>Ээ, простите, а где там пролог?
Там же где и эпилог А>Ленивый, чисто функциональный язык есть, но вот пролог
Ну как бы , если тебе кажется, что там больше похоже на другой "не C++" язык, то заради Бога. Какое это имеет влияние на практическую ценность книжки?
Ну а на пролог похоже, потому что правила сопоставления предикатов пролога очень похожи на правила вывода аргументов шаблона и применения частичных специализаций. В частности, очень похожая техника работы со списками, например
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Всё это перекликается ещё с такой мыслью, что все эти библиотеки, паттерны и приёмы — это готовые решения типовых проблем. И если программист ещё не сталкнулся с этой проблемой, или скорее сталкнулся, но для него ещё не стало очевидно, что это проблема, и что хорошо бы иметь готовое решение для неё, у этого программиста такие вещи, конечно, не будут вызывать ничего кроме недоумения. Конечно он будет говорить, что это ненужное усложнение.
Я в целом согласен, что во всей теории есть и полезное. Я, например, зачем-то книжку таки почитал и Loki посмотрел
Но на практичке я постоянно встречаю людей, которые применяют налево и направо навороты, и совсем не встречаю, таких, которые пишут плохо, потому что наворотов от Александреску не применили
Ну на самом деле задачи просто проще методов Александреску. Увы, такая вот жизнь вокруг меня. Хотя программы в целом непростые, так скажем. И программисты квалифицированные.
Ещё могу поделиться такой историей. У нас тут был недавно сотрудник, который очень хоршо знает и паттерны и STL и вообще всё. Настолько хорошо, что препадаёт это всё в одном уважаемом очень ВУЗе
НУ так вот этот достойный мужчниа нарожал за пол-года море кода, которые потом весь таки извели,заменив радикально более простым и удобным. Но довольно простую прикладную задачу так и не решил
Мало того, то что за последующий год весь его код похерели, это не результат какой-то целенаправленой деятельности по "выжиганию калёным железом", а просто так получилось, потому что так было удобнее. В каждом месте оказалось удобнее не пользоваться наукой
Я это к тому, что до этого случая я думал, что такая, довольно стандартная для не шибкоопытных программистов ситуация, повторилась и у человека довольно знающего и опытного и хорошего. Мне он всегда был симпатичен, но он реально не смог.
Хотя у нас тут задача, которая стояла перед ним, не кажется сложной. Я бы её решил за месяц наверное. Может даже быстрее.
Мало того, потом, с нуля, очень похожую задачу, под руководством довольно мудрого руководителя, решил стажёр. Решил за три с половиной месяца. Правда и стажёр был умный, но он был ориентирован как раз на результат и код "попроще"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Кстати, можно узнать про твоё отношение к исключениям. Ты их используешь в с++?
R>
Исключеня и использую, как и шаблоны и паттерны и много чего ещё. Но я прдерживаюсь парадигмы, что сложное средство нужно использовать только тогда, когда это неизбежно и необходимо. То есть стараюсь писать максимальноп росто.
А вот встречаемые мной в жизни последователи А. стремяться писать так сложно, как только возможно.
Ну а конкртено для исключений я придерживаюсь таких ограничений:
1) Использую для обработки ошибок, но при этом обработчики располагаю в строго регламентированных местах.
2) Использую для обработки запроса пользователя прервать длительную процедуру
3) Использую в некоторой хитрой алгоритмической конструкции. Общее описание давать долго. Дам пример.
Строим сложный объект, содержащий много частей, ссылающихся друг на друга. Объект строим в буфере. С самого начала задаём размер буфера, которого обычно хватает с небольшим запасом. Когда его не хватает -- бросаю исключение, которое ловится в функции создания объекта. Тогда буфер переаллокируется в полтора раза больше и процесс построения объекта повторяется с начала.
Отдельная тема -- что должно происходить с кодом при возникновении исключений. Могу рассказть и про это.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Ничто не мешает задать их так же явно. Например так: R>
R>//Класс TLog должен быть copy-constructable и иметь следующий интерфейс:
R>struct TLog
R>{
R> void log(const std::string&);
R> int fff();
R>};
R>
R>В следующей версии стандарта языка эту проблему возможно решат более элегантно.
Возможно решат, возможно не решат. Я так думаю, что решат, но не ту.
Но в текущем полложении дел есть несколько пробоем.
1а) Никто не гарантирует тебе, что этот твой комментарий соответсвует действительности. Вдруг *на самом деле* ты требуешь от TLog чего-то ещё. Или, наоборот, чего-то пока что не требуешь?
1б) НИкто не гарантирует, что твой комментарий будет правильно понят пользователем. Вдруг он напишет метод int& fff()? И в текущей версии шаблона всё будет хорошо, а потом ты что-то захочешь поправить? А формальной проверки не выполняется.
1в) Не понятно что делать, когда этот коментарий устаревает. Формальных проверок или нет или они чудовищны и ненадёжны. Вот понадобилось тебе, чтобы, скажем, сделать fff возвращал const MyInt&? Что вот делать? Вычитывать весь клиентский код во всех сделвнных на этом шаблоне проектах?
Кроме того, есть у меня такое практическое наблюдение, что когда кто-то пишет шаблон и он при этом не супер спец этого дела, то получается изделие с неясной семантикой. Обычно я не придираясь, а просто стараясь понять что и как там втыкается, задаю вопросы, которые ставят авторов в тупик
Общий смысл такой, что править шаблоны обычно дико дорого, поэтому их можно использовать либо в виде каких-то библиотечных очень хорошо отлаженных примитивов, скажем контейнеров. Либо в каких-то герметичных участках кода, где от чего-то надо несколько раз сдублировать код. Но только второе надо делать уже очень с опаской. Опять же про переиспользование таких шаблонов лучше всего забыть как правило сразу
R>Зато и возможностей больше. Гораздо больше. Причём принципиально новых. Вспомни хотя бы std::vector<>! Как ты его предлагаешь реализовывать без шаблонов? Или ты его не используешь?
Конечно я не возражаю, против шаблонного массива. Но std::vector те не менее не использую. У нас в конторе есть своя, более древняя библиотечка, которая конечно хуже STL, но предсказуемее. Например там более очевидны временные сложности операуий
Ну а если ты о тех новых возможностях, про которые пишет Александреску, то, ИМХО, они лишние
E>>2) Намного более сложный синтаксис и семантика. Вот, например, что тут написано: E>>
E>>template<typename TLog>
E>>class Base {
E>>protected
E>> void exit( int );
E>>};
E>>template<typename TLog>
E>>class MyExitProicessor : public Base<TLog> {
E>>public:
E>> void OnExit( TLog& log, int code )
E>> {
E>> LogExit( log, code ); // это какой-то метод MyExitProicessor, описанный ниже
E>> exit( code );
E>> }
E>>};
E>>
R>Имхо. Всё понятно. Кстати, лучше писать "this->LogExit()" и "this->exit()", тогда и понятнее будет.
Может и лучше, но значит будет другое. Вообще-то в выделенной строке зовут функцию сишную exit . E>>3) Очень неудобные сообщения об ошибках в пользовательском коде.
R>В большинстве случаев точно такие же как и без шаблонов. Надо просто их внимательно прочитать, а не говорить сразу "ух ты #$%, я это даже читать не буду". Вот ещё здесь.
К несчастью мне приходится это читать регулярно. Я так тебе скажу, что до изобретения STL я не встречал сообщений об ошибках, которые не помещаются в окно консоли E>>А вот реальные преимущества всех этих трюков Александреску они в чём? R>Меньше дублирования. Лучше понятны намерения программиста. Аспекты лучше выделены, а не замешаны в один клубок. Но это всё достигается за счёт наличия более сложного (интеллектуального) кода. R>Я так считаю: можно иметь или много "тупого" кода (я его называю "raw"), это когда много накопипастеных функций, или меньше кода, но более "интеллектуального".
Прости, но мне кажется, что все преимущества, кроме "Лучше понятны намерения программиста" достигаются хорошим проектированием и реализацией кода задачи, а вовсе не применением головоломных конструкций из шаблонов
Что же касается намерений, то я согласен, что они понятны. Они обычно (явно или просто по факту) состоят в том, чтобы удорожить разарботку и сопровождение.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Кстати, можно узнать про твоё отношение к исключениям. Ты их используешь в с++?
R>>
E>Исключеня и использую, как и шаблоны и паттерны и много чего ещё. Но я прдерживаюсь парадигмы, что сложное средство нужно использовать только тогда, когда это неизбежно и необходимо. То есть стараюсь писать максимальноп росто. E>А вот встречаемые мной в жизни последователи А. стремяться писать так сложно, как только возможно.
Ну я так понял, что используешь. К чему я это.
Допустим есть достаточно крупное приложение.
Раньше были коды ошибок, которые возвращались из каждой функции. Соответственно после вызова каждой функции код ошибки проверяется, и если ошибка, то код передаётся выше.
Решение максимально простое, понятное, явное (при просмотре кода и дебаге всё видно, всю логику). для использования не надо знать ничего сложного (надо просто знать, как возвращается результат из функции, ну я думаю это знает каждый программист).
Я лично считаю такой подход устаревшим и не подходящим для больших поддерживаемых проектов. Я считаю, что обработка ошибок с помощью исключений гораздо более адекватна задаче. Судя по тому, что ты написал (
"Использую для обработки ошибок, но при этом обработчики располагаю в строго регламентированных местах"
), ты тоже так считаешь.
В крации приемущества: единая система ошибок и политика обработки, не надо "протаскивать" код ошибки через все функции, нет возможности игнорировать ошибку и "забыть" проверить код ошибки и т.д.
Но этот подход гораздо более сложней и главное для его реализации надо знать гораздо больше: механизм распространения и перехвата исключений, политики обработки исключений, границы распространения исключений и т.д.
Некотрые знакомые программисты, которые когда-то давно один раз научились программировать и больше ничего нового не изучают, говорят про исключения примерно следующее: "ну это сложнее" (полностью согласен), "от этого программа падает — забыл в одном месте поймать и всё" (тоже полностью согласен), "это не понятно, это не явно — смотришь на код функции — а обработки ошибок в нём нет" (тоже согласен).
Они тоже называют использование исключений усложнением и непонятной вещью.
Вобщем, что я хочу сказать. Есть вещи более простые, но с мменьшими возможностями (например, возьмёт логарифмическую линейку), а есть вещи более сложные, но с большими возможностями (например, возьмём компьютер). Конечно, человек, который 20 лет проработал с логарифмической линейкой, скажет про использование компьютера, что это сложно, что это не нужно, что это непонятно, что я так привык.
Всё всегда идёт к усложнению и к большим возможностям. Это неизбежно. Но тут надо не отставать от жизни.
Всегда существуют двигатели прогресса, которые исследуют новые возможности, потом облачают их более простую, понятную и пригодную для использованию форму. И после этого новые возможности становятся достоянием народа. Взять, например, современный автомобиль, штука офигеть какая сложная, зато возможностей сколько и использовать как просто. Всё. Мне пора в философию или о жизни
boost.mpl — штука сложная. внутри. но облечённая в удобную для использования форму. и документированная хорошо. Я не вижу ничего плохого в использовании её в промышленном проекте. Я даже надеюсь на то, что когда придёт новый программист, он скажет "о, вы тут mpl используете. конечно я работал с ним. я понимаю этот код".
E>Отдельная тема -- что должно происходить с кодом при возникновении исключений. Могу рассказть и про это.
Занятно. Это как? В обработчике исключения логика, которая ищет исходные коды программы (наверное по pdb) и модифицирует код?
Что может происходить с кодом при возникновении исключения?
E>Общий смысл такой, что править шаблоны обычно дико дорого, поэтому их можно использовать либо в виде каких-то библиотечных очень хорошо отлаженных примитивов, скажем контейнеров. Либо в каких-то герметичных участках кода, где от чего-то надо несколько раз сдублировать код. Но только второе надо делать уже очень с опаской. Опять же про переиспользование таких шаблонов лучше всего забыть как правило сразу
Согласен, в некоторых местах явные интерфейсы более предпочтительны, а шаблоны неумесны.
R>>Зато и возможностей больше. Гораздо больше. Причём принципиально новых. Вспомни хотя бы std::vector<>! Как ты его предлагаешь реализовывать без шаблонов? Или ты его не используешь?
E>Конечно я не возражаю, против шаблонного массива. Но std::vector те не менее не использую. У нас в конторе есть своя, более древняя библиотечка, которая конечно хуже STL, но предсказуемее. Например там более очевидны временные сложности операуий
Ну я надеюсь, что он хотя бы типобезопасный, а не на void* работает
И ещё надеюсь, что мне, что бы захранить в таком контейнере какой-то класс, не надо вначале реализовывать интерфейс IStorable
E> E>>>2) Намного более сложный синтаксис и семантика. Вот, например, что тут написано: E>>>
E>>>template<typename TLog>
E>>>class Base {
E>>>protected
E>>> void exit( int );
E>>>};
E>>>template<typename TLog>
E>>>class MyExitProicessor : public Base<TLog> {
E>>>public:
E>>> void OnExit( TLog& log, int code )
E>>> {
E>>> LogExit( log, code ); // это какой-то метод MyExitProicessor, описанный ниже
E>>> exit( code );
E>>> }
E>>>};
E>>>
R>>Имхо. Всё понятно. Кстати, лучше писать "this->LogExit()" и "this->exit()", тогда и понятнее будет.
E>Может и лучше, но значит будет другое. Вообще-то в выделенной строке зовут функцию сишную exit .
А вот ещё кусок кода:
int* p = 0;
*p = 0;
И без шаблонов. Вывод какой: ламеров надо либо обучать, либо увольнять
E> E>>>3) Очень неудобные сообщения об ошибках в пользовательском коде.
R>>В большинстве случаев точно такие же как и без шаблонов. Надо просто их внимательно прочитать, а не говорить сразу "ух ты #$%, я это даже читать не буду". Вот ещё здесь.
E>К несчастью мне приходится это читать регулярно. Я так тебе скажу, что до изобретения STL я не встречал сообщений об ошибках, которые не помещаются в окно консоли
Меня лично это не пугает.
Я сообщения об ошибках на принтере не печатаю, и за место в консоли арендную плату не плачу
E> E>>>А вот реальные преимущества всех этих трюков Александреску они в чём? R>>Меньше дублирования. Лучше понятны намерения программиста. Аспекты лучше выделены, а не замешаны в один клубок. Но это всё достигается за счёт наличия более сложного (интеллектуального) кода. R>>Я так считаю: можно иметь или много "тупого" кода (я его называю "raw"), это когда много накопипастеных функций, или меньше кода, но более "интеллектуального".
E>Прости, но мне кажется, что все преимущества, кроме "Лучше понятны намерения программиста" достигаются хорошим проектированием и реализацией кода задачи, а вовсе не применением головоломных конструкций из шаблонов
К сожалению, некоторые задачи и некоторые виды дублирования не подвласны в С++ никому кроме шаблонов. Ни явным интерфейсам, ни хорошему проектированию.
К ещё больщему сожалению, некоторые виды дублирования не подвласны даже шаблоным, а подвласны только макросам...
E>Что же касается намерений, то я согласен, что они понятны. Они обычно (явно или просто по факту) состоят в том, чтобы удорожить разарботку и сопровождение.
Те, что используют исключения, паттерны, готовые библиотеки да и вообще С++ по-твоему те же намерения имеют? Вообще надо на asm'е писать. Всё до примитивного просто и явно.
Согласен практически со всем написанным в этом посте и выше , того же автора. Толкьо вот использование самодельных векторов меня как то покоробило , пора с этим заканчивать!
Здравствуйте, minorlogic, Вы писали:
M>Согласен практически со всем написанным в этом посте и выше , того же автора. Толкьо вот использование самодельных векторов меня как то покоробило , пора с этим заканчивать!
R>Вобщем, что я хочу сказать. Есть вещи более простые, но с мменьшими возможностями (например, возьмёт логарифмическую линейку), а есть вещи более сложные, но с большими возможностями (например, возьмём компьютер). Конечно, человек, который 20 лет проработал с логарифмической линейкой, скажет про использование компьютера, что это сложно, что это не нужно, что это непонятно, что я так привык. R>Всё всегда идёт к усложнению и к большим возможностям. Это неизбежно. Но тут надо не отставать от жизни. R>Всегда существуют двигатели прогресса, которые исследуют новые возможности, потом облачают их более простую, понятную и пригодную для использованию форму. И после этого новые возможности становятся достоянием народа. Взять, например, современный автомобиль, штука офигеть какая сложная, зато возможностей сколько и использовать как просто. Всё. Мне пора в философию или о жизни
Ну вот примеров удачного использования исключений я видел много, а шаблонов -- мало. А вот идей Александреску -- ни одного случая
На самом деле код без исключений не такой уж и плохой обычно. Но с исключениями немного лучше всё-таки. В том числе надёжнее.
Но надежнее он, кстати, не из-за исключений, а из-за scope guards, продуманной схемы владения объектами и другихарихитектурных достижений.
Собственно улучшают прогамму в основном они.
А уж когда ты их внедрил, то код с исключеними становится проще и понятнее
А что и куда надо внедрить, чтобы стал проще и понятнее код с мультиметодами, например, я не знаю
R>boost.mpl — штука сложная. внутри. но облечённая в удобную для использования форму. и документированная хорошо. Я не вижу ничего плохого в использовании её в промышленном проекте. Я даже надеюсь на то, что когда придёт новый программист, он скажет "о, вы тут mpl используете. конечно я работал с ним. я понимаю этот код".
Всё хорошо, но я не знаю зачем он нужен. В том смысле что не знаю примеров удачного его использования
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, igna, Вы писали:
E>>Ну а если ты о тех новых возможностях, про которые пишет Александреску, то, ИМХО, они лишние I>Лишние кому/для кого?
Для разработки на C++ нужных людям и легкоподдерживаемых программ
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Здравствуйте, minorlogic, Вы писали:
M>>Согласен практически со всем написанным в этом посте и выше , того же автора. Толкьо вот использование самодельных векторов меня как то покоробило , пора с этим заканчивать!
R>А самодельные smart_ptr'ы, фабрики и т.д.?
R>
То же самое по возможности заменять стандартными. Про фабрики ничего не скажу а вот смартпоинтер лучше бустовский.
Здравствуйте, minorlogic, Вы писали:
M>Согласен практически со всем написанным в этом посте и выше , того же автора. Толкьо вот использование самодельных векторов меня как то покоробило , пора с этим заканчивать!
Ну традиция, переиспользование кода и всё такое.
Если честно, то если бы std::vector был лучше, или хотя бы так же хорош, то на него наверное перешли бы. Но он слишком таки абстрактен и не во всех аспектах предсказуем.
Но в целом я согласен. Лучше конечно переходить на стандартные средства
Хотя мне вот лично даже MFC'шный CArray больше нравится, как впрочем и сериализация
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
M>>Согласен практически со всем написанным в этом посте и выше , того же автора. Толкьо вот использование самодельных векторов меня как то покоробило , пора с этим заканчивать!
R>А самодельные smart_ptr'ы, фабрики и т.д.?
Да все фабрики самодельные. Редко бывают такие сложные задачи, что нужно автоматизировать написание фабрик
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Константин Л., Вы писали:
КЛ>Если менее квалифицированный кадр чего-то не знает — это не повод не использовать это "чего-то". Могу сказать по собственному опыту — большой проект с большой текучкой программистов, которые не слышали про итераторы( причем тут А. не понимаю, он про них не пишет и не он их придумал.) — это самоубийство. И мне наплевать, слышали они про std::vector или нет, мне нужна надежная работающая программа и от std::vector из-за какого-то Васи(Феди...) я от него не откажусь, лучше от Васи(Феди...) откажусь, пусть технологии учит...
Я согласен с тобой, что от std::vector стоит отказываться только в случае если есть что-то лучше. Так как хуже уже точно опускаться не стоит.
Но вот от списков типов и от Loki я бы отказался однозначно во всех известных мне проектах.
Хотя "бы" тут даже лишнее. Пока что я во всех отказался
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Константин Л., Вы писали:
КЛ>Если этого требует задача, и это решение проанализировано, то почему нет?
Ну приведи же наконец пример реальной задачи, где всё это великолепие нужно!
Я вот таких задач не знаю
E>>2) Во-вторых, эта книжка мне нравится потому, что там очень хорошо и на примерах описано насколько плохо программировать таким образом КЛ>Сложно — бесспорно, плохо — смотря для чего.
Ну собственно пока что всегда удавалось писать проще. К чему бы это?
E>>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет КЛ>А. тут ни при чем, шаблоны сами по себе сложны. Ты против А. или против шаблонов? Мне кажется 2-oe.
Ну вот шаблонный массив, особенно если без итераторов, константных итераторов, какими-нибудь аллокаторами попроще немного, без связанных аллокаторов и т. д. очень даже и хорош бывает. Но даже и std::vector вполне приемлем.
Но то, что делает с шаблонами А -- это точно совершенно в реальной жизни малоприменимо. Если тебе так не кажется, приводи примеры арихитектур и задач, где это таки нужно и хорошо.
E>>Но при этом не особо опытные инженеры этого всего не понимают и очень сильно переусложняют код.
E>>Так что очень может быть, что стиот почитать вские умные книжки на эту тему, особенно про паттерны проектирования, но главная идея должна быть такая, что никогда не забывать точно ли это нужно для реально возникающих в твоей деятельности задач. КЛ>Золотые слова. Но если ты в своей деятельности не встречаешься с задачами, которые требуют применения таких извращений, это не значит, что другие не встречаются.
Ну вот я имею наглость утверждать, что я уже много чего повидал на почве программирования.
Приводи таки примеры задач, где фокусы от А. и Loki в частности полезны и нужны
E>>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.
КЛ>Я бы не был столь категоричным. Большинство того, что он там пишет можно и нужну использовать. Просто надо знать "что?где?когда?". Никто не говорит о использовании typelists в приложении на 20 .h/.cpp., которое кажет 1 диалог с 2-мя кнопками... Если я не ошибась, А. сам пишет о том, что нужно искать компромиссы, здравые решения для каждой конкретной ситуации.
Ну вот мне и кажется, что обычно лучший копромис -- "не использовать"
Мало того, мне кажется, что сам А. тоде так думает
Но я так и не понял согласен ли ты с выделенным?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Константин Л., Вы писали:
E>>Я согласен с тобой, что от std::vector стоит отказываться только в случае если есть что-то лучше. Так как хуже уже точно опускаться не стоит. E>>Но вот от списков типов и от Loki я бы отказался однозначно во всех известных мне проектах. E>>Хотя "бы" тут даже лишнее. Пока что я во всех отказался КЛ>Да я тоже их не использую, но это не значит что они сакс и нигде не пригодны. Если появится задача, при решении котрой они мне помогут, я буду их использовать.
Ну я же не говорю, что не надо использовать никогда, потому что некошерно. Я просто скромно прошу сообщить мне, если кому-то удастся применить это счастье во благо
Собственно у меня к тебе личная просьба. Если такой пример вдруг отыщется, то сообщи о нём нам всем. Ладно?
Ещё есть такая тонкость, что я подозреваю что большинство участников обсуждения, не смотря на весь энтузиазм, не встречали задач, где всё это полезно
Хотя это не значит, что все они воздержались от использования.
Ну и уж тем более вряд ли встречал автор оригинального топика, который попросил объяснить как и зачем применить книжку А. Так как он не совсем понимает, что там написано, хотя это всё ему и нравится.
Так что я вполне гуманно разъясняю всю бессмысленность попыток применения А. на практике
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, alexeiz, Вы писали:
E>А вообще интересно, почему тебе кажется, что скорее LISP, а не Prolog?
Именно на LISP, т.к. Александреску сам об этом явно упоминает в книге Перед тем как представить макросы для списков типов
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
E>>>Я согласен с тобой, что от std::vector стоит отказываться только в случае если есть что-то лучше. Так как хуже уже точно опускаться не стоит. E>>>Но вот от списков типов и от Loki я бы отказался однозначно во всех известных мне проектах. E>>>Хотя "бы" тут даже лишнее. Пока что я во всех отказался КЛ>>Да я тоже их не использую, но это не значит что они сакс и нигде не пригодны. Если появится задача, при решении котрой они мне помогут, я буду их использовать.
E>Ну я же не говорю, что не надо использовать никогда, потому что некошерно. Я просто скромно прошу сообщить мне, если кому-то удастся применить это счастье во благо
E>Собственно у меня к тебе личная просьба. Если такой пример вдруг отыщется, то сообщи о нём нам всем. Ладно?
E> E>Ещё есть такая тонкость, что я подозреваю что большинство участников обсуждения, не смотря на весь энтузиазм, не встречали задач, где всё это полезно E>Хотя это не значит, что все они воздержались от использования. E>Ну и уж тем более вряд ли встречал автор оригинального топика, который попросил объяснить как и зачем применить книжку А. Так как он не совсем понимает, что там написано, хотя это всё ему и нравится. E>Так что я вполне гуманно разъясняю всю бессмысленность попыток применения А. на практике
Что ты зациклился на списках типов? Там еще куча полезных фич. Часть 1я глава 2я — Int2Type, Type2Type, TypeTraits и т.п.
Вот список глав из 2-ой части А.Александреску "Современное проектирование на с++. Обобщенное программирование и прикладные шаблоны проектирования."
1) Обощенные функторы (не использую, а ты? Применимость — хз, но думаю средняя)
2) Реализация шаблона Singleton (В какой-то степени, а ты? Применимость — почти каждый юзает в том или ином виде)
3) Интеллектуальные указатели (юзаю, а ты? то же, что и предыдущий)
4) Фабрики объектов (не изаю, нет необходимости. А ты? Применимость — имхо средняя)
5) Шаблон Abstract Factory (см. пред. пункт)
6) Шаблон Visitor (к своему сожалению юзаю в 1ом месте, а ты? Пременимость — пр. пункт)
7) Мультиметоды (не юзаю, а ты? Пр. — низкая(ИМХО))
Кроме практической ценности эта книга имеет очень большую теоретическую ценность.
Re[4]: Чем хороша книжка Александреску
От:
Аноним
Дата:
17.04.06 15:06
Оценка:
Здравствуйте, remark, Вы писали:
R>Да, но читать-то и знать всё это надо. R>Энание и опыт не придёт никак иначе, кроме как через использование.
В книге написано, что она предназначена для опытных программитов. Для неопытных лучше почитать чего попроще. Вообще, жалко, что появляющиеся языки программирования, не стремятся сделать обобщнное и метапрограммирование доступным широким слоям.
ИМХО из TBL-файлов можно бы генирировать и что-то более понятное и удобное
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Аноним, Вы писали:
А>В книге написано, что она предназначена для опытных программитов. Для неопытных лучше почитать чего попроще. Вообще, жалко, что появляющиеся языки программирования, не стремятся сделать обобщнное и метапрограммирование доступным широким слоям.
Почему жалко именно это?
Скорее надо жалеть или не жалеть о том, что обобщённое и метапрограммирование широким слоям нафиг не сдалось
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
КЛ>>2) Реализация шаблона Singleton (В какой-то степени, а ты? Применимость — почти каждый юзает в том или ином виде) E>Не использую. Мало того, считаю, что самая хорошая реализация синглетона -- это что-то типа: E>
E>class CMySingletonObject {
E> // тут что-то такое
E>};
E>extern CMySingletonObject MySingletonObject;
E>
Смотря для чего
КЛ>>3) Интеллектуальные указатели (юзаю, а ты? то же, что и предыдущий) E>Использую, но не такие сложные, как у А. Но шаблонные E>НО конкретно в умных указателях, ИМХО, А. нисего нового и при этом полезного не сказал.
Он это сказал аж в 2002 году. Для кого-то это не ново, для кого-то ново.
КЛ>>6) Шаблон Visitor (к своему сожалению юзаю в 1ом месте, а ты? Пременимость — пр. пункт) E>Почему к сожалению и о чём именно ты сожалеешь? О том, что используешь или о том, что используешь один раз?
О том, что 1 раз .
E>Мне известно о четырёх серъёзных попытках использовать этот шаблон. Все четыре провалились. То есть потом код был всё-таки переписан, без визитора и стал проще, лучше, понятнее и всё такое.
Нууу, я всей темы не знаю. Мало-ли как вы там его писали и нужен ли он был вообще . Я юзал 1 раз и остался очень доволен
Erop wrote: > C>Списки типов генерируется с помощью Comet из TLB-файлов ( > C>http://www.lambdasoft.dk/comet/index.htm ). > ИМХО из TBL-файлов можно бы генирировать и что-то более понятное и удобное
Понятнее — можно
А вот удобнее — вряд ли. Через пару недель использования Comet'овских
стабов при необходимости использовать ATL тянет перейти нафиг на C#
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[6]: Чем хороша книжка Александреску
От:
Аноним
Дата:
17.04.06 16:05
Оценка:
Здравствуйте, Erop, Вы писали:
E>Почему жалко именно это? E>Скорее надо жалеть или не жалеть о том, что обобщённое и метапрограммирование широким слоям нафиг не сдалось
Если бы обобщённое программирование заключалось не в том, что надо писать template<class T>, а в том, что не надо писать тип параметра функции, к нему относились бы подругоиму.
[skipped]
E>>>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.
КЛ>>Я бы не был столь категоричным. Большинство того, что он там пишет можно и нужну использовать. Просто надо знать "что?где?когда?". Никто не говорит о использовании typelists в приложении на 20 .h/.cpp., которое кажет 1 диалог с 2-мя кнопками... Если я не ошибась, А. сам пишет о том, что нужно искать компромиссы, здравые решения для каждой конкретной ситуации.
E>Ну вот мне и кажется, что обычно лучший копромис -- "не использовать" E>Мало того, мне кажется, что сам А. тоде так думает
E>Но я так и не понял согласен ли ты с выделенным?
Хорошая программа — это:
1) программа, котрая делает то, что нужно
2) имеет мало багов
3) которую легко сопровождать и добавлять функционал
твое высказывание не относится к 1,2
3 — спорно и зависит в большей степени от того, как написана, и насколько сложна, нежели с помощью чего написана.
А вообще, простые программы писать проще. Да еще и выбросив на свалку все библиотеки
Всем нравится простой код, а "крутой" еще больше
Здравствуйте, Константин Л., Вы писали:
КЛ>Нууу, я всей темы не знаю. Мало-ли как вы там его писали и нужен ли он был вообще . Я юзал 1 раз и остался очень доволен
Ну писали хорошо довольно. Но не шмогли всё равно прислонить с толком
А вообще интересно бы узнать задачу.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Аноним, Вы писали:
А>Если бы обобщённое программирование заключалось не в том, что надо писать template<class T>, а в том, что не надо писать тип параметра функции, к нему относились бы подругоиму.
Да и называлось оно иначе как-нибдь. Perl-coding, скажем
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
C>Есть. Оно понимает только Automation-compatible интерфейсы, в результате C>обертки для IStream/IStorage пришлось писать самому по образу и подобию C>Comet.
То есть, она не понимает не-IDispatch унаследованных интерфейсов или ей не нравится когда в методы передаются не Variant-совместимые типы? А то ведь в ActiveX море интерфейсов которые не унаследованы от IDispatch...
Вообще интересен совет от профессионала который этой библиотекой пользовался — стоит ли вообще тратить время на то чтобы с ней разбираться или преимущества её перед ATL не стоят свеч?
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Аноним, Вы писали:
А>>В книге написано, что она предназначена для опытных программитов. Для неопытных лучше почитать чего попроще. Вообще, жалко, что появляющиеся языки программирования, не стремятся сделать обобщнное и метапрограммирование доступным широким слоям.
E>Почему жалко именно это? E>Скорее надо жалеть или не жалеть о том, что обобщённое и метапрограммирование широким слоям нафиг не сдалось
Цитата из статьи Страустропа "A rationale for semantically enhanced library languages":
The focus will be on templates because they provide the key mechanism for statically type-safe expression of advanced ideas in C++
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
КЛ>>Ну от некоторых частей буста я тоже в шоке — трудно для понимания, с наскоку не разберешся. E>+1
Хочу заметить, что тут может играть роль наше подсознательное (или сознательное) чувство того, что мы так написать не можем (мозгов не хватает), и из-за этого может появится неприятие, непонимание, и даже отвращение ко всяким там бустам и т.п.
Здравствуйте, jazzer, Вы писали:
J>Грубо говоря, если тебе нужно нечто вроде for_each(v, v+size, mem_fun_ptr), то если у тебя нет под рукой STL — ты напишешь цикл и не будешь париться, а если под рукой есть STL — ты заюзаешь for_each. Но несмотря на все преимущества for_each, если у тебя нет STL, то ради одного for_each городить всю многофайловую инфраструктуру из iterator, algorithm, functional и т.д. несколько неумно. Но если оно уже есть — почему бы этим не воспользоваться?
Я вот не особо понимаю что же за преимущества у for_each? Мне for в данном конкретном случае и понятнее и приятнее и если не дай божи чего не работате, меня не утянет "под капот" откуда я может и не вынырну без помощи более опытного товарища
J>Я к тому, что нельзя с мерками прикладного кода подходить к библиотечному коду. А Александреску выступает именно как разработчик библиотек, и ничего страшного не произойдет, если ты, помимо STL, подключишь Loki, потому что пользоваться ею, насколько я понимаю — не сложнее, чем STL. А вся александресковская сложность — под капотом, ты ее и не увидишь и дела с ней иметь не будешь. Укажешь в параметрах типа, что именно тебе надо — и вперед.
Ну вот мне не известно удачных случаев применения библиотеки Loki. В сложном коде, в простом, в очень сложном. Короче в любом.
Мало того, я сильно подозреваю, что их никто не сможет привести.
Хотя мне известны попытки. Все в конце концов неудачные. Как на уровне использования Loki, так и на уровне использования идей А.
J>А то, что ты пишешь про прикладной код — это все правильно и я с этим полностью согласен.
Ну я пишу простую вещь. Что не придумали ещё задач, которые столь сложны, что их решать проще с помощью Loki, чем без её помощи
Вернее задачи может и придумали, но жизнь их пока не просит разрешить
Мне не нравится парадигма "сделать так сложно, как только можно".
Мне нравится парадигма "сделать так просто, как только можно".
Понятно что слишком просто делать дорого. Но всё-таки стремиться надо к простоте, а не к сложности.
Если, например, у тебя протая программа, которая интегрирует 20 COM-объектов между собой, то напиши её на VB или на C# и не парь себе мозг без нужды с Comet
.
Понятно, что если у тебя сложный проект, который ещё к тому же и 100 COM-объектов интегрирует и сам много чего нетривильного делает и почему-то никак не удобно все мозги засунуть в 101-й COM-объект, а менеджер этого барахла забомбить таки на VB, то тогда конечно проще будет с наворотами. Но это только тогда и только если действительно проще не сделать. А не всегда, когда есть такая возможность, раз уж мы научились писать такие решения не слишком задорого.
При этом соображения о том, что "все сложности под капотом" не многое тут меняет. Потому что эти все сложности с нами. Мне и std::vector не нравится потому, что он заради довольно простой функциональности, рожает нереально много всяких сложных довесочков. И от них нельзя просто отказаться.
Я бы, например, предпочёл, чтобы возможность использования алгоритмов подключалась в stl по явному требованию. А не была намертво в него вцементирована всегда. Почему? Потому что каждый раз, когда где-то, как правило в каком-то неудачном коде написанным невнимательным новичком, портится память, так я попадаю мордой под этот капот.И вынужден там ковыряться. И при этом пользы-то никакой от наворотов я не получаю. Получаю гемор, поучаю догую компиляцию, получаю причудливую зависимость от версий компиляторов и библиотек и много чего ещё "хорошего". А вот реально хорошего от этой всей сложности получаю мало. Потому что все "выгоды", заради которых всё так непросто, они мне не нужны. И я не думаю, что потому, что я учавствую в разработке слилшком простых программ.
Я ещё раз призываю рассказать где же оно всё бывает нужно-то?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
КЛ>>Нууу, я всей темы не знаю. Мало-ли как вы там его писали и нужен ли он был вообще . Я юзал 1 раз и остался очень доволен E>Ну писали хорошо довольно. Но не шмогли всё равно прислонить с толком E>А вообще интересно бы узнать задачу.
Есть иерархия полиморфных объектов, которые отображаются в комбобоксе. При изменении текущего объекта в комбике надо апдейтать UI(кнопочки, радиобаттоны и т.п.). Вот для этой хрени я и заюзал визиторов. Иерархия состоит из 3х(!) классов. И вот из-за них я и замутил все это дело с визиторами. Скажешь зачем, ведь проще было if'ов напихать? Да, проще, но я решил что:
а) так красивее (просто мне нравится!)
б) потом если придется добавить 4, 5, 6 класс я пойму, что сделал правильный выбор.
НО, у visitors есть свои нехилые недостатки (взаимозависимости) и никто не говорит о том, что это панацея.
Если я не ошибаюсь , то патерн визитор , полезен в иерархии где изменение базовых классов недопустимо , в вашем случае это было так ? Т.е. действительно нельзя было добавить пару виртуальных функций ?
Здравствуйте, Left2, Вы писали:
L>Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно.
Насколько я понял 4, 5, 6 -- это клиенты. А визитор посещает контролы.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, _DAle_, Вы писали:
_DA>На самом деле книга вышла в начале 2001 года. Наверное, пять лет назад она была чем-то новым и интересным. А на мой вкус, если нужна книжка о шаблонах, то сейчас есть замечательная "C++ Templates: The Complete Guide", про паттерны тоже надо читать не Александреску. А вот если возникла идея реализовать свой велосипед аналогичный какому-нибудь из Loki-велосипедов, то в книжку эту можно и заглянуть, чтобы посмотреть описание одного из путей реализации и граблей с ним связанных.
Но главная польза, ИМХО, в том, что можно на всё это поглядеть и задуматься. Точно ли это таки надо?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, Erop, Вы писали:
E>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>Нууу, я всей темы не знаю. Мало-ли как вы там его писали и нужен ли он был вообще . Я юзал 1 раз и остался очень доволен E>>Ну писали хорошо довольно. Но не шмогли всё равно прислонить с толком E>>А вообще интересно бы узнать задачу.
Ну вроде как эту же задачу решают при помощи property sheets. И всё хорошо вроде как выходит. И без всяких визиторов. И контроды можно для разных объектов иметь вообще разные, с произвольно устроенной логикой. И попроще всё. И менять легче.
Или я чего-то не догнал?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Константин Л., Вы писали:
КЛ>>>Ну от некоторых частей буста я тоже в шоке — трудно для понимания, с наскоку не разберешся. E>>+1
КЛ>Хочу заметить, что тут может играть роль наше подсознательное (или сознательное) чувство того, что мы так написать не можем (мозгов не хватает), и из-за этого может появится неприятие, непонимание, и даже отвращение ко всяким там бустам и т.п. КЛ>
Увы, но я могу. Просто я стараюсь себя ограничивать, так как понимаю насколько это таки деструктивно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Left2, Вы писали:
КЛ>>Есть иерархия полиморфных объектов, которые отображаются в комбобоксе. При изменении текущего объекта в комбике надо апдейтать UI(кнопочки, радиобаттоны и т.п.). Вот для этой хрени я и заюзал визиторов. Иерархия состоит из 3х(!) классов. И вот из-за них я и замутил все это дело с визиторами. Скажешь зачем, ведь проще было if'ов напихать? Да, проще, но я решил что: КЛ>>а) так красивее (просто мне нравится!) КЛ>>б) потом если придется добавить 4, 5, 6 класс я пойму, что сделал правильный выбор.
КЛ>>НО, у visitors есть свои нехилые недостатки (взаимозависимости) и никто не говорит о том, что это панацея.
L>Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно.
Не совсем. Добавление нового класса влечет за собой добавление новых методов void Visitor::Visit( SomeNewType& ); void SomeNewType::Accept( Visitor* ).
При этом меняется только интерфейс Visitor'а. Новые операции появляются за счет создания наследников Visitor'а. Так что о не применимости этого паттерна к иерархии, которая изменяется( в большинстве же случаев она разрастается ) не совсем корректно. Как раз о ее применимости и пишет господин А.
Кстати, она у меня скорее всего не изменится никогда.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Left2, Вы писали:
L>>Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно.
E>Насколько я понял 4, 5, 6 -- это клиенты. А визитор посещает контролы.
Он посещает клиентов, и, в зависимости от того, что за клиент, он изменяет статусы контролов.
Здравствуйте, Константин Л., Вы писали:
L>>>Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно. E>>Насколько я понял 4, 5, 6 -- это клиенты. А визитор посещает контролы. КЛ>Он посещает клиентов, и, в зависимости от того, что за клиент, он изменяет статусы контролов.
Тогда действительно не понятно при чём тут visitor?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
КЛ>>Здравствуйте, Erop, Вы писали:
E>>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>>Нууу, я всей темы не знаю. Мало-ли как вы там его писали и нужен ли он был вообще . Я юзал 1 раз и остался очень доволен E>>>Ну писали хорошо довольно. Но не шмогли всё равно прислонить с толком E>>>А вообще интересно бы узнать задачу.
E>Ну вроде как эту же задачу решают при помощи property sheets. И всё хорошо вроде как выходит. И без всяких визиторов. И контроды можно для разных объектов иметь вообще разные, с произвольно устроенной логикой. И попроще всё. И менять легче.
E>Или я чего-то не догнал?
Здравствуйте, Константин Л., Вы писали:
КЛ>Не совсем. Добавление нового класса влечет за собой добавление новых методов void Visitor::Visit( SomeNewType& ); void SomeNewType::Accept( Visitor* ). КЛ>При этом меняется только интерфейс Visitor'а. Новые операции появляются за счет создания наследников Visitor'а. Так что о не применимости этого паттерна к иерархии, которая изменяется( в большинстве же случаев она разрастается ) не совсем корректно. Как раз о ее применимости и пишет господин А. КЛ>Кстати, она у меня скорее всего не изменится никогда.
Но, казалось бы, операция у тебя всего одна -- типа выбрали элемент.
На кой тебе визитёр?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, minorlogic, Вы писали:
M>Если я не ошибаюсь , то патерн визитор , полезен в иерархии где изменение базовых классов недопустимо , в вашем случае это было так ? Т.е. действительно нельзя было добавить пару виртуальных функций ?
Откуда такая информация? Каких виртуальных функций?
Упрощенный смысл визитора в том, что он позволяет статически выбирать тип объекта с помощью динамического механизма. Т.е. выбор типа объекта, с которым будем работать, делает сам объект, статически.
Здравствуйте, Константин Л., Вы писали:
E>>Или я чего-то не догнал? КЛ>property sheets тут не подходят
А почему?
Я так понял, что у тебя есть список элементов. В зависимости от типа выбранного элемента ты показываешь разные контролы и устраиваешь между ними другое взаимодействие.
Ну типа есть список людей, и окно с их свойствами, которые можно редактировать. Типа у женщин одни кнопки у мужчин другие у детей третьи. Иногда они совпадают иногда нет. Могут перемещаться, запрещаться, прятаться и т. д.
Обычно это делают при помощи PS. Что мешало так поступить и тебе?
Или я задачу совсем не понял?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Константин Л., Вы писали:
КЛ>Захотелось сделать так. А насколько это оправданно?... Просто тогда мне показалось это более целесообразным. Может быть завтра я посмотрю на тот код и удивлюсь, зачем я так сделал.
Ну в общем "и так каждый раз" (с) известный анекдот.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
E>>>Или я чего-то не догнал? КЛ>>property sheets тут не подходят
E>А почему? E>Я так понял, что у тебя есть список элементов. В зависимости от типа выбранного элемента ты показываешь разные контролы и устраиваешь между ними другое взаимодействие.
E>Ну типа есть список людей, и окно с их свойствами, которые можно редактировать. Типа у женщин одни кнопки у мужчин другие у детей третьи. Иногда они совпадают иногда нет. Могут перемещаться, запрещаться, прятаться и т. д.
E>Обычно это делают при помощи PS. Что мешало так поступить и тебе?
E>Или я задачу совсем не понял?
Почти. Есть комбик для выбора текущего айтэма. Есть 2 кнопки, которые грэются в зависимости от него. Есть группа радиобаттонов, которые тоже могут грэиться. Есть листвью. В общем, все контролы общие, и я даже не думал делать это через ps. Кроме того, как ты стал бы выбирать, какой ps показывать? Опять же, либо if'ы, либо vf'ы, либо visitors. Надеюсь, теперь понятно?
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
КЛ>>Захотелось сделать так. А насколько это оправданно?... Просто тогда мне показалось это более целесообразным. Может быть завтра я посмотрю на тот код и удивлюсь, зачем я так сделал.
E>Ну в общем "и так каждый раз" (с) известный анекдот.
Тебе всегда нравится код, который ты писал полгода назад?
Здравствуйте, Константин Л., Вы писали:
КЛ>Тебе всегда нравится код, который ты писал полгода назад?
Константин! Я же не говорю, что ты мегакривой проект реализовал
Я говорю, что если бы ты сразу не стал с визитором связываться, то было бы и лучше и проще и при следующем рефакторинге всё равно выбросишь
Мы же обсуждали хорошо ли стало кому от визитёра, например.
А так не всегда. Правда мне обычно не нравится уже на след. день
Так что стараюсь сделать так, чтобы через полгода не испугаться ещё больше.
А так нормально всё. Но я так понял, что визитёр там был таки с горяча?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Константин Л., Вы писали:
КЛ>Почти. Есть комбик для выбора текущего айтэма. Есть 2 кнопки, которые грэются в зависимости от него. Есть группа радиобаттонов, которые тоже могут грэиться. Есть листвью. В общем, все контролы общие, и я даже не думал делать это через ps. Кроме того, как ты стал бы выбирать, какой ps показывать? Опять же, либо if'ы, либо vf'ы, либо visitors. Надеюсь, теперь понятно?
Я бы сделал map из типа item'а в страничку.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
КЛ>>Тебе всегда нравится код, который ты писал полгода назад?
E>Константин! Я же не говорю, что ты мегакривой проект реализовал E>Я говорю, что если бы ты сразу не стал с визитором связываться, то было бы и лучше и проще и при следующем рефакторинге всё равно выбросишь
нет, все работает и выглядит неплохо
E>Мы же обсуждали хорошо ли стало кому от визитёра, например.
мне стало)))
E>А так не всегда. Правда мне обычно не нравится уже на след. день E>Так что стараюсь сделать так, чтобы через полгода не испугаться ещё больше.
+1
E>А так нормально всё. Но я так понял, что визитёр там был таки с горяча?
50/50
С одной стороны можно было обойтись if'ми, с другой код стал более строже
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
E>>>А так нормально всё. Но я так понял, что визитёр там был таки с горяча? КЛ>>50/50 КЛ>>С одной стороны можно было обойтись if'ми, с другой код стал более строже
E>Ну скажем так, что этот пример меня не убедил E>Мне кажется, что место вообще простое, понятное, и какой визитор не привенти -- сильно не испортишь, но в принципе без визитора проще
проще. Но не значит лучше )
E>Хотя для "потренироваться" полигон выбран грамотно
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, minorlogic, Вы писали:
M>>Если я не ошибаюсь , то патерн визитор , полезен в иерархии где изменение базовых классов недопустимо , в вашем случае это было так ? Т.е. действительно нельзя было добавить пару виртуальных функций ?
КЛ>Откуда такая информация? Каких виртуальных функций? КЛ>Упрощенный смысл визитора в том, что он позволяет статически выбирать тип объекта с помощью динамического механизма. Т.е. выбор типа объекта, с которым будем работать, делает сам объект, статически.
Здравствуйте, ekamaloff, Вы писали:
E>Здравствуйте, mukos, Вы писали:
M>>(вчера читал у Майерса чьето высказывание (может его) "Нужно писать просто насколько M>>возможно ,но не более"(хотя вроде это был Шекспир))
E>
Здравствуйте, remark, Вы писали:
R>И эту библиотеку тоже придётся поддерживать вместе с проектом. Т.ч. дублирование не умесно. А в с++, к сожалению, только самые примитивные виды дублирования можно устранить с помощью обычных функций. Если можно с помощью функции, то я конечно не против такого простого решения. Но часто просто не получается с помощью функции. Часто только ОО-подходы могут устанить дублирование. А часто и ОО-подходам это не под силу, тогда как-раз шаблоны и приходят на помощь (заметьте речь идёт о прикладном проекте). А иногда и шаблонам не под силу устранить дублирование, ну уж тогда на помощь приходят всеми нами любимые макросы.
да всё таки и есть в целом.
Только прикольно, что в качестве крайнего средства предлагаются не шаблонные шаблонные параметры, как у А., а макросы
Но это всё не про книжку А.
Там предлагаются навороты, которые ИМХО ни в каком реальном проекте не пригодятся
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Некоторые виды дублирования нельзя устранить ни какими способами, кроме advanced-templates (не считая таких отстойных вещей как макросы и void*).
R>Моё обоснование использования advanced-templates в двух указанных выше предпосылках.
R>По мимо очень большой скорости правки кода, тебе так же понадобиться идеальная внимательность, т.к. при исправлении какого-либо аспекта в паре десятков мест надо везде сделать правильно.
R>Идеальной внимательностью я кстати тоже не обладаю, поэтому не люблю, когда мне приходится "поправлять" десятки "почти похожих мест" в проекте.
Прекрасно!
Расскажи как тебе помогают в твоих многочисленных бедах мультиметоды и for_each
Главная проблема с шаблонами, ИМХО, такая, что часто при редактировании нетривильного шаблона очень трудно предсказать все последствия.
Так что кроме идеальной внимательности нужна ещё и идеальная проницательность, доходящая до уровня провидца
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Ну вот мне не известно удачных случаев применения библиотеки Loki. В сложном коде, в простом, в очень сложном. Короче в любом. E>Мало того, я сильно подозреваю, что их никто не сможет привести. E>Хотя мне известны попытки. Все в конце концов неудачные. Как на уровне использования Loki, так и на уровне использования идей А.
Используем SOA в промышленном проекте. Кроме этого, активно используем ScopeGuard.
E>Мне не нравится парадигма "сделать так сложно, как только можно". E>Мне нравится парадигма "сделать так просто, как только можно".
Главное, чтобы за этими благими намерениями не скрывалось банальное нежелание/неспособность изучать и применять новые прогрессивные идеи и средства.
Здравствуйте, Left2, Вы писали:
A>>1) Кто-нибудь захочет создать еще один объект CMySingletonObject, и у него это получится. L>Ну, эта-то проблема разрешима в пол-пинка Никто не мешает сделать конструкторы-деструкторы закрытыми. К основной идее это отношения не имеет.
Создай глобальный объект после этого. Остальные твои аргументы в той же колее. Зачем начинать с глобального объекта, если ты потом начинаешь приделывать к нему возможности синглтона? Ты таким образом признаёшь, что глобальный объект, как синглтон никуда не годится.
A>Создай глобальный объект после этого.
Ну ладно, ладно — делаем ему друга и инстанцируем его через друга. Друг тоже в .cpp и никому не виден.
A> Остальные твои аргументы в той же колее. Зачем начинать с глобального объекта, если ты потом начинаешь приделывать к нему возможности синглтона? Ты таким образом признаёшь, что глобальный объект, как синглтон никуда не годится.
Затем чтобы не иметь проблем с синхронизацией. Не нужны примитивы синхронизации для создания обьекта.
A>> Остальные твои аргументы в той же колее. Зачем начинать с глобального объекта, если ты потом начинаешь приделывать к нему возможности синглтона? Ты таким образом признаёшь, что глобальный объект, как синглтон никуда не годится. L>Затем чтобы не иметь проблем с синхронизацией. Не нужны примитивы синхронизации для создания обьекта.
И ещё одна (как по мне так главная) причина — дабы не тащить к себе библиотеку в которой синглтоны реализованы (т.е. не добавлять зависимостей в проект) и не реализовывать её самому.
Здравствуйте, Left2, Вы писали:
A>>> Остальные твои аргументы в той же колее. Зачем начинать с глобального объекта, если ты потом начинаешь приделывать к нему возможности синглтона? Ты таким образом признаёшь, что глобальный объект, как синглтон никуда не годится. L>>Затем чтобы не иметь проблем с синхронизацией. Не нужны примитивы синхронизации для создания обьекта.
L>И ещё одна (как по мне так главная) причина — дабы не тащить к себе библиотеку в которой синглтоны реализованы (т.е. не добавлять зависимостей в проект) и не реализовывать её самому.
Твоё отношение к сторонним библиотекам крайне отрицательно, тогда как решение использовать ту или иную библиотеку — это просто компромис. В нём есть и за и против. Ты видешь только одно против.
Здравствуйте, Left2, Вы писали:
A>>Твоё отношение к сторонним библиотекам крайне отрицательно, тогда как решение использовать ту или иную библиотеку — это просто компромис. В нём есть и за и против. Ты видешь только одно против.
L>Почему же крайне отрицательно? Отнюдь, когда библиотека облегчает мне работу с предметной областью — то я двумя руками и двумя ногами за. Но тащить тот же boost::singleton к себе в проект ради чистоты концепции — увольте
Отнюдь не ради чистоты концепции, а чтобы облегчить работу своим сотрудникам и освободить их от необходимости разбираться в самопальном синглтоне.
>Благо, 90% всех синглтонов можно сделать на коленке описанным способом за 5 минут.
У тебя даже объяснить это толком не получается, не говоря уже о том, чтобы сделать.
L>>Почему же крайне отрицательно? Отнюдь, когда библиотека облегчает мне работу с предметной областью — то я двумя руками и двумя ногами за. Но тащить тот же boost::singleton к себе в проект ради чистоты концепции — увольте
A>Отнюдь не ради чистоты концепции, а чтобы облегчить работу своим сотрудникам и освободить их от необходимости разбираться в самопальном синглтоне.
Да в чём там разбраться-то?? Сотрудники что — не знают что такое глобальные переменные?
>>Благо, 90% всех синглтонов можно сделать на коленке описанным способом за 5 минут.
A>У тебя даже объяснить это толком не получается, не говоря уже о том, чтобы сделать.
Правильно — вот это наш способ вести разговор. "Что может думать по этому поводу человек с лысиной и таким носом? Пусть сначала отрастит волосы, исправит нос — а потом высказывает своё мнение!"
Здравствуйте, alexeiz, Вы писали:
E>>4) Ну и главное. В целом очень редко в программировании попадаются такие сложные задачи, что нужно то, что описано у Александреску скажем.
A>здесь
Я же не говорю, что книжка непонятная. Я говорю другое, только младенец в инженерном деле может рискнуть её использовать
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Alex_Avr, Вы писали:
E>>accumulate, как мне кажется, не читабельнее чем for, copy тоже. E>>merge -- уже чем-то лучше, но нужен редко E>>Мапы и сортировку я использую из конторской библиотеки примитивов. A_A>Код, в котором используется STL более переносим, чем "конторская библиотека", хоть, может быть, и менее удобен для каких-то задач. A_A>По поводу переносимости кода с использованием STL — ниже.
Неправда. У меня есть конкретно довольно большой опыт переноса разного кода под разные платформы. Иногда очень-очень сложного инаогда не очень. Если самописаня библиотека не написана слишком умно, то она конечно же переносимее.
A_A>Вообще гворя STL — это просто описание в Стандарте некоторых интерфейсов и некоторых требований к их реализации. A_A>Так что переносимость как таковая зависит от того, кто ее _реализует_. A_A>Если же требуется действительная переносимость с платформы на платформу, то что мешает использовать A_A>STLPort (здесь список поддерживаемых компиляторов) A_A>или SGI STL?
(за ссылки спасибо, но мимо кассы)
Заменть реализацию STL обычно что-нибудь мешает. Так что реализация STL обычно навязывается целевой платформой, особенно если ты портишь библиотеку
Про qsort я согласен кроме млочей.
1) во многих случаях qsort вполне пригоден. Скажем переделывать код заради изведения qsort я стану только если что-то ещё надо
2) У нас есть своя реализация шаблонной сортировки. Она без многих чудес, сделана из какого-то популярного в CS алгоритма и довольно хорошо работает.
3) stable_sort, как я понимаю, менее эффективен
E>>Мало того, про "сложность под капотом" я уже писал. Обычно я сижу как раз под этим капотом и пытаюсь понять кто же и что накосячил в клиентском коде, E>что эту прекрасную и мощную библиотеку так загнуло-заломало? A_A>Я думаю, что кривые руки могут сломать любую библиотеку , по этому мне это не кажется весомым аргументом.
Да кривые руки могут всё. Поэтому защищаться от них путём пложения шаблонных монстров ИМХО плохо.
Проблема в том, что когда кривые руки ломают простую библиотеку, то даже под капотом мне легко, а когда STL -- нет. А задачи-то решаемые простой библиотекой и STL примерно одни и те же.
E>>Собственно поинт состоит в том, что всё это виликолепие не нужно E>>Мне вполне хватает трёх умных указателей. Один для COM-объектов, и он не наш, а баблиотечный, один просто scope_guard, с запретом копирования. (На самом деле он бывает векторным и скалярным, но первый мне пока что не пригождался). Првда по историческим причинам он давно очень у нас реализован и им и пользуемся. И ещё один со счётчиком. Он предполагает, что имущество, которым он владеет является public virtual наследником некоего класса, в котором реализован счётчик. E>>Собственно больше мне ничего от умных указателей ни разу не понадобилось. A_A>Зато это "великолепие" может быть нужно многим другим разработчикам.
Ну вот в нашей конторе пока что пригодился ещё векторный scope guard, да и то, ИМХО, со зла
A_A>Loki конечно далеко не идеал, но ведь она изначально, насколько я понимаю, была предназначена для иллюстрации A_A>идей Александреску, а не для промышленного применения. Тем не менее том же Boost кое-где используются A_A>подходы, аналогичные реализованным в Loki.
Я согласен. И некоторые идеи позитивны. Негативен вектор. Когда люди ценят не как проще, а как круче, гибче дуракозащищённее и т. д.
Когда "сложность под капотом" не считают недостатком. И уж тем более хуже когда недостатком не считают просто сложгность. Типа говорят "ну и что что сложно, а мы модульный тест навернём и будет так же надёжно"
A_A>И я не думаю, что в каждой конторе такие специалисты найдутся. Так что иногда выгоднее и проще использовать готовые решения, A_A>"с наворотами", но решающие эффективно поставленные задачи, чем писать велосипеды.
Я согласен, что если уж совсем всё плохо, то лучше использовать STL, но бы опростил несколько vector да и пользовался, если честно
A_A>Но при реализации больших проектов возможность расширения/развития/добавления функциональности тоже является A_A>немаловажной частью этой самой задачи. И здесь решения с "наворотами", но более гибкие, могут быть A_A>предпочтительнее "простого" кода. Опять же, все зависит от конкретной ситуации.
Что-то я вот не пойму, как поддержка итераторов в STL скажем добавляет гибкости и возможностей развития в код автоматической коробки передач? ИМХО всё это счастье добавляет хорошо продуманная архитектура проекта. А многим неопытным инженерам кажется, что намного важнее применить какой-то сверхумный и сверхгибкий указатель, да ещё проследить, чтобы не было goto
A_A>Так это относится к использованию любых средств языка и при использовании любых парадигм программирования. A_A>Бездумное примение чего-либо всегда приводит написанию кода, который проще выбросить и переписать заново.
Ну вот практически все попытки использовать Loki и приёмы оттуда я воспринимаю, как безумные
A_A>Может просто не использовать эти лишние для вас особенности? Например с стандартах кодирования явно запретить использовать все, A_A>что связано с итераторами.
Да "под капотом" они всё равно останутся
E>>Мне, кстати, в std::vector еще не нравится, что в operator[] не проверяют границ. A_A>Да, в operator[] нет проверки допустимости индекса, чтобы его могли использовать A_A>без потери производительности те, кому эта проверка не нужна. Кому проверка нужна A_A>могут использовать std::vector::at () вместо std::vector::operator[](). A_A>В лучае выхода индекса за допустимы границы at() бросает исключение.
Да знаю я STL
Я говорю, что мне там не нравится. Я бы предпочёл иметь метод fast_get_at, для тех кому проверка не нужна.
Просто STL контейнеры оптимизированы под некоторый стиль кодирования. С итераторами, функторами, алгоритмами и т. д.
Поэтому-то им проверки и не нужны. Ты в клиентском коде почти не должен лазить в вектора непосредственно.
А алгоритмы типа отлажены.
А мне вся эта парадигма гажется неоправданно переусложнённой, так что я с радостью выбросил бы и итераторы и отсутсвие проверок в самом частотном доступе к элементу и т. д.
Реально для этакого "опрощённого" кодирования, STL хорошо бы проредить и передезайнить.
A_A>А что бы изменилось, если бы использовались самописные функции/классы, а не из STL? A_A>Разве что в реализации STL обычно используются так сказать, "обфусцированные" имена переменных и объектов, поэтому отлаживать A_A>ее труднее.
Да просто всё сложнее устроено в структурах данных. И труднее найти концы.
E>>Я собственно просил рассказть о случае удачного применения loki A_A>Судя по всему, тут уже пошел разговор о применимости STL и решениях, примененных Александреску в Loki, в реальной жизни. A_A>Я Loki не использую, но кое-какие идеи его я применяю при написании своего кода. Boost, где используются A_A>кое-какие аналогичные решения, я использую по мере надобности (там есть много полезных вещей и без "наворотов").
Ну boost очень разнороден. Содержит и дельные вещи, но навороты ИМХО всё время не по делу.
Ну а STL, как я уже писал не под то немного заточен. Всё-таки он несколько более sofisticated, чем хотелось бы.
Ну а Loki, ИМХО, неприменима. Хотя и на оригинальном Pascal люди проекты рожали, хотя тоже учебный язык вроде как был поначалу
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, programmater, Вы писали:
P>Здравствуйте, Константин Л., Вы писали:
КЛ>>Здравствуйте, minorlogic, Вы писали:
M>>>Если я не ошибаюсь , то патерн визитор , полезен в иерархии где изменение базовых классов недопустимо , в вашем случае это было так ? Т.е. действительно нельзя было добавить пару виртуальных функций ?
КЛ>>Откуда такая информация? Каких виртуальных функций? КЛ>>Упрощенный смысл визитора в том, что он позволяет статически выбирать тип объекта с помощью динамического механизма. Т.е. выбор типа объекта, с которым будем работать, делает сам объект, статически. P>Ой как сказал. Я бы не понял, если бы не знал о чем речь . А я вот не использую visitor. Из прынцыпа. Я до сих пор использую двойную диспетчеризацию (в контексте, как она описана здесь), потому как считаю, что полезная содержательная суть визитора — это двойная диспетчеризация. Все остальное — это навороты и от лукавого. И в основном для того, чтобы дотянуть его до "паттерна проектирования". Поправьте меня, если я не прав.
Прочитал. Так паттерн визитор и есть двойная диспетчеризация, о которой я и написал.
А под "он позволяет статически выбирать тип объекта с помощью динамического механизма" я имелл ввиду это
class CCasino: public CBuilding
{
public:
virtual void doDraw (CMap* map)
{
map->doDraw(*this);
};
};
, т.е. уже на этапе компиляции выбирается метод doDraw
Здравствуйте, Left2, Вы писали:
L>>>Почему же крайне отрицательно? Отнюдь, когда библиотека облегчает мне работу с предметной областью — то я двумя руками и двумя ногами за. Но тащить тот же boost::singleton к себе в проект ради чистоты концепции — увольте
A>>Отнюдь не ради чистоты концепции, а чтобы облегчить работу своим сотрудникам и освободить их от необходимости разбираться в самопальном синглтоне.
L>Да в чём там разбраться-то?? Сотрудники что — не знают что такое глобальные переменные?
>>>Благо, 90% всех синглтонов можно сделать на коленке описанным способом за 5 минут.
A>>У тебя даже объяснить это толком не получается, не говоря уже о том, чтобы сделать.
L>Правильно — вот это наш способ вести разговор. "Что может думать по этому поводу человек с лысиной и таким носом? Пусть сначала отрастит волосы, исправит нос — а потом высказывает своё мнение!"
, как ты тсчетно пытаешься объяснить, как из глобальной переменной сделать синглтон.
И? Что я сказал непонятного? Я действительно говорю об использовании глобальной переменной в качестве синглтона. "тсчетность" (я так понял это тщетность?) в чём?
Здравствуйте, Erop, Вы писали:
A>>Вообще, надо иметь смелость сказать, что глобальные объекты эквивалентны синглтонам. E>Ну я имею смелость заявить даже больше: "Синглетоны -- это и есть глобальные объекты. От синглетонов не надо ничего большего, по сравнению с глобальными объектами"
Есть такое мнение, что разница между Синглетон и глобальным объектом заключается в том, что глобальный объект создаётся сразу, а Синглетон — при первом обращении.
ЗЫ Естественно, можно и глобальный объект сделать как PIMPL с IMPL, создающимся по требованию, но это уже Синглетон , хотя в паттернах нет явных границ, так что как хотите так и называйте.
"programmater" <34509@users.rsdn.ru> wrote in message news:1859643@news.rsdn.ru... > Здравствуйте, Константин Л., Вы писали: > > КЛ>Здравствуйте, minorlogic, Вы писали: > > M>>Если я не ошибаюсь , то патерн визитор , полезен в иерархии где изменение базовых классов недопустимо , в вашем случае это было так ? Т.е. действительно нельзя было добавить пару виртуальных функций ? > > КЛ>Откуда такая информация? Каких виртуальных функций? > КЛ>Упрощенный смысл визитора в том, что он позволяет статически выбирать тип объекта с помощью динамического механизма. Т.е. выбор типа объекта, с которым будем работать, делает сам объект, статически. > Ой как сказал. Я бы не понял, если бы не знал о чем речь . А я вот не использую visitor. Из прынцыпа. Я до сих пор использую двойную диспетчеризацию (в контексте, как она описана здесь), потому как считаю, что полезная содержательная суть визитора — это двойная диспетчеризация. Все остальное — это навороты и от лукавого. И в основном для того, чтобы дотянуть его до "паттерна проектирования". Поправьте меня, если я не прав.
Так в этом примере, на который ты ссылаешься, именно визитор и описан. В данном примере CMap — это визитор. А вообще визитор это только один из вариантов реализации того, что называется двойной дипетчеризацией. Как здесь было уже отмечено, главным его недостатком является невозможность расширения классов-участников диспетчеризации без модификации базового класса визитора.
Другой известной реализацией является реализация с помошью двумерного массива обработчиков. У этого метода преимущество в том, что он позволяет расширять набор участников двойной диспетчеризации даже в клиентском коде, а недостаток — в том, что необходимо обеспечить механизм преобразования типов классов в индексы, а это задача далеко не тривиальная.
Posted via RSDN NNTP Server 2.0
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Константин Л., Вы писали:
J>>На мой взгляд, этот паттерн — один из самых неудачных. КЛ>Неудачных паттернов не бывает. У всех у них есть свои недостатки и преимущества. Неудачным бывает место его применения. К тому же, там все просто до ужаса, в чем там можно запутаться? Ну да ладно, вам виднее.
Там все просто, пока ты остаешься на уровне 'hello world', пока не дойдет до реального кода, который выдержал с десяток запросов от бизнеса/пользователей.
А в реальном коде все превращается в монстра типа того, о котором я рассказал.
У тебя ведь у самого реального опыта с этим паттерном нет, насколько я понимаю из треда выше.
Вот когда твой код с визиторами таким образом (десяток выполненных запросов) заматереет, тогда и поговорим.
Я вполне допускаю, что сейчас тебе все нравится, но вот что останется от этого кода после того, как по нему 10 раз пройдутся программисты, решая совершенно разные задачи, которые перед ними поставили пользователи? Насколько им будет удобно ворочаться в твоей визиторской структуре?
Насколько после этих перепахиваний код останется красивым и простым, и вообще останется ли он, или очередной бедолага, у которого вдруг оказалось свободное время, просто возьмет и перепишет все заново?
L>И тут же возникает соблазн вкрутить его куда-нибудь. Это куда-нибудь как правило ну очень отдалённо похоже на visitor. Но настоящему инженеру море по колено — и вот, получите визитора там где он ну совсем не нужен .
Angler wrote: > doc->>GetPage(page_num)->GetItem(item_num)->SetSelected(false); > Ну это смотря как импортировать библиотеку типов: > #import <msxml4.tlb> > rootNode->appendChild(node->GetownerDocument()->createElement(L"name")); > Правда это удобно только в клиентском коде
Вот в этом все и различие. MSVS при импорте просто генерирует удобные
обертки для использования, а Comet — расширяемые стабы.
Здравствуйте, Left2, Вы писали:
L>Догадываюсь почему, сам наступал на такие грабли L>Дело в том что визитор довольно нетривиальный и крассивый паттерн. <...> Ну а после этого пишет на RSDN поднимая вопрос о правомочности существования визитора как такового и паттернов вообще
Согласен, более или менее, кроме как с тем, что не чиал книжк уи не знаю в чём состоит тот или иной паттерн
Но поинт был не в том, чот паттерны не нужны вообще, а в том, что практически всегда не возникает нужды в подавляющем боьшинстве паттернов
Примеров что-то пока никто убедительных не привёл пока. В том числе и про визитёра
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Anton V. Kolotaev, Вы писали:
AVK>Typelist'ы из Loki применяются в Nebula-2 — open source графическом движке.
А зачем?
Казалось бы граф. движок не должне быть сверхсложен архитектурно.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Вобщем, что я хочу сказать. Есть вещи более простые, но с мменьшими возможностями (например, возьмёт логарифмическую линейку), а есть вещи более сложные, но с большими возможностями (например, возьмём компьютер). Конечно, человек, который 20 лет проработал с логарифмической линейкой, скажет про использование компьютера, что это сложно, что это не нужно, что это непонятно, что я так привык. R>>Всё всегда идёт к усложнению и к большим возможностям. Это неизбежно. Но тут надо не отставать от жизни. R>>Всегда существуют двигатели прогресса, которые исследуют новые возможности, потом облачают их более простую, понятную и пригодную для использованию форму. И после этого новые возможности становятся достоянием народа. Взять, например, современный автомобиль, штука офигеть какая сложная, зато возможностей сколько и использовать как просто. Всё. Мне пора в философию или о жизни
E>Ну вот примеров удачного использования исключений я видел много, а шаблонов -- мало. А вот идей Александреску -- ни одного случая E>На самом деле код без исключений не такой уж и плохой обычно.
Ну это пока проект не особо большой. А когда проект переступает определённую черту, то коды ошибок начинают постепенно всасывать, причём со временем всё больше. имхо.
E>Но с исключениями немного лучше всё-таки. В том числе надёжнее. E>Но надежнее он, кстати, не из-за исключений, а из-за scope guards, продуманной схемы владения объектами и другихарихитектурных достижений. E>Собственно улучшают прогамму в основном они. E>А уж когда ты их внедрил, то код с исключеними становится проще и понятнее
Но согласись, что усключения гораздо более сложная вещь, чем коды возврата, что для их применения надо знать больше, что код становится не таким очевидным (особенно для людей, знакомых с исключениями поверхностно).
E>А что и куда надо внедрить, чтобы стал проще и понятнее код с мультиметодами, например, я не знаю
Тут ты путаешь.
Есть понятие "что" (если на примере с исключениями, то "что" — это необходимость тем или иным способом обрабатывать ошибочные ситуации)
И есть "как" (на примере с исключениями, "как" — это обрабатывать ошибочные ситуации с помощью исключений, или обрабатывать ошибочные ситуации с помощью кодов возврата)
Так вот, мультиметоды — это "что", а не "как".
Т.е. если провести аналогию с исключениями, то твоё предложение звучит как "куда можно внедрить обработку ошибочных ситуаций?". Очевидно, что если внедрять обработку ошибочных ситуаций в программу, которой совершенно не надо обрабатывать ошибочные ситуации, т.е. в которой нет понятия "ошибочная ситуация", то код действительно от такого внедрения не станет ни проще, ни понятнее.
Я хочу сказать, что мультиметоды нужно внедрять только туда, где есть мультиметоды как таковые. Точнее надо внедрять реализацию мультиметодов.
Я совершенно согласен, что мультиметоды вещь достаточно редкая, поэтому к ним такое и отношение. Но А тут совершенно ни при чём. Он лишь предложил достаточно хорошую реализацию мультиметодов. Но в том, что это редкая вещь, он не виноват.
R>>boost.mpl — штука сложная. внутри. но облечённая в удобную для использования форму. и документированная хорошо. Я не вижу ничего плохого в использовании её в промышленном проекте. Я даже надеюсь на то, что когда придёт новый программист, он скажет "о, вы тут mpl используете. конечно я работал с ним. я понимаю этот код".
E> E>Всё хорошо, но я не знаю зачем он нужен. В том смысле что не знаю примеров удачного его использования
Причём, что бы первая вызывалась для типов int, unsigned, short, unsigned short, long, __int64. А вторая для string, wstring, const char*, const wchar_t*.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, remark, Вы писали:
R>>Здравствуйте, qqqqq, Вы писали:
M>[skiped...] R>>Не используем паттерны проектирования и сложную архитектуру, т.к. могут придти программисты не разбирающиеся в этом. M>[skiped...]
M>Конечно не используем "сложную архитектуру" но применяем патерны. Задача патернов — упростить архитектуру а не наоборот. M>хорошая архитектура == простая архитектура, самая простая которая решает поставленные задачи.
Как бы то ни было, паттерны тоже не применяем, т.к. не все же студенты знакомы с ними. Ну оканчивается название класса на Visitor. Ну и что? Кому-то это ничего не скажет.
Так что 20 функций из С и ни фичей больше
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, remark, Вы писали:
R>>Т.е. ты предлагаешь взять пересечение множеств умений всех программистов, которые работают и могут работать в будущем над проектом.
J>Этот подход тоже вполне имеет право на существование. J>Чем менее квалифицированные программисты нужны, тем меньше риски проекта, потому что в любой момент ты можешь взять с улицы первого попавшегося и он вольется в команду за пару дней. J>А если сидит квалифицированный перец, который мыслит исключительно рекурсивными шаблонами — то даже если ты построишь процесс разработки так, что все будет хорошо, пока этот программист в штате, что случится, когда он уйдет? Кто подхватит знамя? Аналогичного по скиллам ты быстро не найдешь, а проект все это время должен развиваться (банально должны оперативно фикситься баги), а не ждать, когда же придет очередная звезда с "шаблонным" мышлением.
А почему я именно так должен процесс построить? Я процесс построю (построил), так что квалифицированный перец постепенно обучит всю команду этим рекурсивным шаблонам. И если команда решит, что это действительно прогрессивно для проекта, что уменьшает дублирование и т.д. То все будут это использовать, и все будут это понимать, и ни у кого никаких проблем не будет. И если возьмут с улицы нового программиста, то он тоже через какое-то время обучится всем общим техникам.
А если процесс строиить как ты предлашаешь, то тут по любому будут проблемы. И рекурсивные шаблоны тут ни при чём. Проблемы будут хотя бы в том, что один перец будет сидеть и планомерно переназывать переменные value_ в m_iValue по всему проекту, а его сосед будет планомерно переназывать переменные m_iValue в value_ по всему проекту.
Пока команда не поймёт, что она команда, и что она работает над одним проектом, а не каждый по отдельности работает над своей задачей. Пока команда не вырабатает общие правила, техники, стили и приёмы. Пока команда не будет работать на одном уровне. Пока команда не начнёт использовать одну парадигму программирования. Проблемы будут по-любому.
А уж если команда — это команда. То тут она может себя не ограничивать в средствах. И использовать наиболее эффективные на её взгляд. Тут она может пользоваться не пересечением, а объединением множеств умений.
Имхо.
Есть только одна ситуация, в которой такой подход может не работать. Это когда собственно команды нет как таковой. Т.е. вначале полгода проект пописал один программист. Потом он уволился. Потом ещё через полгода наняли ещё одного программиста продолжать проект. В такой ситуации согласен с точкой зрения, которую ты привёл. Но только в такой ситуации. Если же есть команда, которая постоянно состоит хотя бы из двух-трёх человек, то не согласен.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Константин Л., Вы писали:
J>>>На мой взгляд, этот паттерн — один из самых неудачных. КЛ>>Неудачных паттернов не бывает. У всех у них есть свои недостатки и преимущества. Неудачным бывает место его применения. К тому же, там все просто до ужаса, в чем там можно запутаться? Ну да ладно, вам виднее.
J>Там все просто, пока ты остаешься на уровне 'hello world', пока не дойдет до реального кода, который выдержал с десяток запросов от бизнеса/пользователей. J>А в реальном коде все превращается в монстра типа того, о котором я рассказал. J>У тебя ведь у самого реального опыта с этим паттерном нет, насколько я понимаю из треда выше. J>Вот когда твой код с визиторами таким образом (десяток выполненных запросов) заматереет, тогда и поговорим.
J>Я вполне допускаю, что сейчас тебе все нравится, но вот что останется от этого кода после того, как по нему 10 раз пройдутся программисты, решая совершенно разные задачи, которые перед ними поставили пользователи? Насколько им будет удобно ворочаться в твоей визиторской структуре? J>Насколько после этих перепахиваний код останется красивым и простым, и вообще останется ли он, или очередной бедолага, у которого вдруг оказалось свободное время, просто возьмет и перепишет все заново?
Здравствуйте, remark, Вы писали:
E>>Ну вот примеров удачного использования исключений я видел много, а шаблонов -- мало. А вот идей Александреску -- ни одного случая E>>На самом деле код без исключений не такой уж и плохой обычно.
R>Ну это пока проект не особо большой. А когда проект переступает определённую черту, то коды ошибок начинают постепенно всасывать, причём со временем всё больше. имхо.
В целом я абсолютно согласен, что есть некоторый объём сложности задачи, когда обработка ошибок при помощи продуманного использования исключений, и при условии внедрения некоторых других правил (полезных безотносительно получается проще и поддерживаемее, чем при помощи кодов возврата.
Ещё я согласен, что при помощи исключений можно написать более надёжную и предсказуемую программу. Но при этом это надо суметь сделать. Тем не менее, хотя сами по себе исключения сложнее кодов возврата, порог этот низкий очень и в многих задачах обрабатывать ошибки при помощи исключений проще. И тогда их конечно же надо использовать.
Но, скажем, в такой программе:
int main( int, const char*[] )
{
chra c;
while( cin >> c )
cout << c;
return 0;
}
Исключения использовать, ИМХО, неправильно
R>Но согласись, что усключения гораздо более сложная вещь, чем коды возврата, что для их применения надо знать больше, что код становится не таким очевидным (особенно для людей, знакомых с исключениями поверхностно).
Я конечно согласен, что сложнее. Но про "людей, занкомых поверхностно" -- это немного мимо кассы. Конструкции из Loki не годятся даже для людей неповерхностно знакомых с шаблонами Они просто слишком сложные.
R>Я совершенно согласен, что мультиметоды вещь достаточно редкая, поэтому к ним такое и отношение. Но А тут совершенно ни при чём. Он лишь предложил достаточно хорошую реализацию мультиметодов. Но в том, что это редкая вещь, он не виноват.
Крнечно не виноват! Это его заслуга, что он смог придумать столь редкую задачу и решение для неё. Просто вся эта штука очень далека от реальной жизни
А виноват чувак, который решает внедрить мультиметоды туда, где они не нужны. Потому что так "покруче" будет
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Как бы ты предложил это реализовать?
Обычно я стараюсь делать так, чтобы у перегруженных функций была общая семантика.
И тут тоже скорее всего назвал бы по-разному
Но это неудачно, если ты хочешь, чтобы всё вокруг было шаблонным.
Но обычно я и этого избегаю
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
A_A>>Для расширения кругозора — можно узнать причины, которые мешают заменить используемую реализацию STL на другую, кроме заточенности A_A>>кода на особенности конкретной реализации и своих доработок ее напильником? E>Примеры причин, которые я встречал E>...
Спасибо.
A_A>>STL такая, какая есть, потому что нацелена на универсальность использования, а более общее и универсальное решение A_A>>всегда сложнее более частного решения. E>Ну так я про то и спорю, что идеология, что если есть возможность вместо конкретного средства забацать (или использовать) "универсальный всемогутер", то надо делать всемогутер. А мне кажется, что нужно ровно наоборот. Чем меньше всемогутеров и чем менее они универсальны, тем обычно это ближе к оптимальному инженерному решению, а идея многих неопытных программистов и даже, как это не печально, многих преподавателей, ровно противоположенная
Чем более специализировано решение, тем более узка область его применения.
Соответственно, количество нобходимых "могутеров" возрастает при росте их специализированности.
В пределе — под каждую задачу с нуля пишется специализированное решение, что далеко не всегда оправданно.
Поэтому нужен баланс между простотой и универсальностью решения.
E>>>А многим неопытным инженерам кажется, что намного важнее применить какой-то сверхумный и сверхгибкий указатель, да ещё проследить, чтобы не было goto A_A>>Понимание многих вещей приходит только с опытом. E>Ну можно считать, что я пытаюсь им делиться, но некоторые с ним не согласны
Я бы удивился, если бы все были согласны. У каждого свой опыт и свой взгляд на вопросы разработки ПО.
Поэтому утверждение "STL — зло" не для всех является истинным , и для этого есть свои резоны.
Здравствуйте, remark, Вы писали:
E>>Но на практичке я постоянно встречаю людей, которые применяют налево и направо навороты, и совсем не встречаю, таких, которые пишут плохо, потому что наворотов от Александреску не применили R>Повезло
А ты часто встречал людей, которые написали плохой код именно потому, что не применили идеи А?
Опиши как это было-то?
E>>Ну на самом деле задачи просто проще методов Александреску. Увы, такая вот жизнь вокруг меня. Хотя программы в целом непростые, так скажем. И программисты квалифицированные. R>Смотря какие подразумевать критерии хорошего решения задачи?
Успешные многолетние проекты. С большим числом версий, миллионами инсталляций по миру. Поддержка, развите. Очень сложные задачи в смысле того, что не очевидно как это реализовывать вообще, сложные пользовательсткие интерфейсы и т. д.
Есть, в том числе, и программы, являющимися лучшими или одними из лучших в мире в своих сегментах. R>Если только наличие требуемого поведения, то тогда конечно любую задачу можно решить очень просто...
Сопровождение и развитие ещё требуется.
R>Меня лично интересует только то, что начикается со слов practical или applied.
+1
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Anton V. Kolotaev, Вы писали:
E>>Казалось бы граф. движок не должне быть сверхсложен архитектурно. AVK> Интересно, на чем основано это мнение?
Ну, скажем так, он дожен быть намного проще ОС, например.
Нет? Возможно я неправильно понгимаю, что скрывается за словми "графический движок"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
E>>Прекрасно! E>>Расскажи как тебе помогают в твоих многочисленных бедах мультиметоды и for_each
E>>Главная проблема с шаблонами, ИМХО, такая, что часто при редактировании нетривильного шаблона очень трудно предсказать все последствия.
R>Одно из свойств advanced-templates в том, что "уж если вся эта бойда скомпилировалась, значит она работает так, как надо". Я в этом сам неоднократно убеждался на примере boost::bind.
Ну, в целом, ты совсем не ответил на мой вопрос
R>Ты фактически описываешь то, что ты хочешь получить декларативно. Да, иногда, вызывает проблемы объяснить компилятору, что же именно ты хочешь получить, что бы он понял. Но уже если объяснил, то это работает. Т.к. ты не описывал, как ты хочешь это получить. А ошибки бывают обычно именно в этом.
Ну в целом подход похвальный. Но есть две беды.
1) Очень уж неудобный язык описания моих желаний
2) Компилятору-то я может и объясню, но лучше бы объяснять тому, кто будет этот код поддерживать
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Alex_Avr, Вы писали:
A_A>Поэтому нужен баланс между простотой и универсальностью решения.
Конечно, просто мне кажется, что в STL баланс неоправданно смещён в сторону универсальности. Вот, скажем, в каких языках было нужно реализовывать алгоритм merge в библиотеке?
E>>>>А многим неопытным инженерам кажется, что намного важнее применить какой-то сверхумный и сверхгибкий указатель, да ещё проследить, A_A>Поэтому утверждение "STL — зло" не для всех является истинным , и для этого есть свои резоны.
Ну это понятно. Но я не считаю STL злом. Я злом считаю стремление к переусложнению кода. STL, имхо, пал жертвой этой моды, но безусловно это полезная и нужная библиотека. Просто если её "опростить" для нужд своего проекта, то она станет ещё лучше
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
E>>>Ну вот примеров удачного использования исключений я видел много, а шаблонов -- мало. А вот идей Александреску -- ни одного случая E>>>На самом деле код без исключений не такой уж и плохой обычно.
R>>Ну это пока проект не особо большой. А когда проект переступает определённую черту, то коды ошибок начинают постепенно всасывать, причём со временем всё больше. имхо. E>В целом я абсолютно согласен, что есть некоторый объём сложности задачи, когда обработка ошибок при помощи продуманного использования исключений, и при условии внедрения некоторых других правил (полезных безотносительно получается проще и поддерживаемее, чем при помощи кодов возврата. E>Ещё я согласен, что при помощи исключений можно написать более надёжную и предсказуемую программу. Но при этом это надо суметь сделать. Тем не менее, хотя сами по себе исключения сложнее кодов возврата, порог этот низкий очень и в многих задачах обрабатывать ошибки при помощи исключений проще. И тогда их конечно же надо использовать. E>Но, скажем, в такой программе: E>
Я согласен, что и идеи А в такой программе применять не стоит
R>>Но согласись, что усключения гораздо более сложная вещь, чем коды возврата, что для их применения надо знать больше, что код становится не таким очевидным (особенно для людей, знакомых с исключениями поверхностно).
E>Я конечно согласен, что сложнее. Но про "людей, занкомых поверхностно" -- это немного мимо кассы. Конструкции из Loki не годятся даже для людей неповерхностно знакомых с шаблонами Они просто слишком сложные.
Я тебя уверяю, что есть вещи гораааздо более сложные, и при этом люди, которым это надо разбираются в них очень хорошо.
Как пример, могу привести некоторые раздели физики — типа квантовой механики, СТО и т.д.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Как бы ты предложил это реализовать?
E>Обычно я стараюсь делать так, чтобы у перегруженных функций была общая семантика. E>И тут тоже скорее всего назвал бы по-разному E>Но это неудачно, если ты хочешь, чтобы всё вокруг было шаблонным. E>Но обычно я и этого избегаю
У них абсолютно одинаковая семантика — "создать реализацию интерфейса ISome для переданного значения".
Ну так как бы ты это решил?
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
E>>>Прекрасно! E>>>Расскажи как тебе помогают в твоих многочисленных бедах мультиметоды и for_each
E>>>Главная проблема с шаблонами, ИМХО, такая, что часто при редактировании нетривильного шаблона очень трудно предсказать все последствия.
R>>Одно из свойств advanced-templates в том, что "уж если вся эта бойда скомпилировалась, значит она работает так, как надо". Я в этом сам неоднократно убеждался на примере boost::bind. E>Ну, в целом, ты совсем не ответил на мой вопрос
Долго
R>>Ты фактически описываешь то, что ты хочешь получить декларативно. Да, иногда, вызывает проблемы объяснить компилятору, что же именно ты хочешь получить, что бы он понял. Но уже если объяснил, то это работает. Т.к. ты не описывал, как ты хочешь это получить. А ошибки бывают обычно именно в этом.
E>Ну в целом подход похвальный. Но есть две беды. E>1) Очень уж неудобный язык описания моих желаний
Есть немного. Покрайней мере непривычный.
E>2) Компилятору-то я может и объясню, но лучше бы объяснять тому, кто будет этот код поддерживать
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Alex_Avr, Вы писали:
A_A>>Поэтому нужен баланс между простотой и универсальностью решения. E>Конечно, просто мне кажется, что в STL баланс неоправданно смещён в сторону универсальности. Вот, скажем, в каких языках было нужно реализовывать алгоритм merge в библиотеке?
А какие ещё языки предназначены для создания библиотек?
Здравствуйте, remark, Вы писали:
E>>Обычно я стараюсь делать так, чтобы у перегруженных функций была общая семантика. E>>И тут тоже скорее всего назвал бы по-разному E>>Но это неудачно, если ты хочешь, чтобы всё вокруг было шаблонным. E>>Но обычно я и этого избегаю
R>У них абсолютно одинаковая семантика — "создать реализацию интерфейса ISome для переданного значения". R>Ну так как бы ты это решил?
Если нет больше подробностей, то я ответил уже как бы я это решил
Обычно такая нужда (перегружать функции по каким-то формальным принципам) возникает когда мы хотим эту функцию потом позвать из шаблона.
У меня обычно таких желаний не возникает. Я согласен, что если всё усложнить, всюду завести шаблоны и т. д., то такая нужда возникнет и ты как миленький или заведёшь себе велосипед какой или пойдёшь компилять на своём компиляторе boost. Никуда не денешься. Это плата за усложнение кода. Так как реально в языке это всё хреново поддержано, то всё быстро обрастает нереально сложными костылями.
Так понятно?
STL, boost и Loki не дураки же писали. Просто людям нравится программировать с шаблонами, при этом они стараются применять их везде, где это хоть зачем-то нужно. Так как шаблоны в C++ спроектированы хреново, то приходится рожать продвинутые шаблоны, для того, чтобы и они нигде не тёрли, и в результате вместо дублирования небольшого куска кода, получается мегабайт бреда, который якобы "под капотом".
ИМХО это всё неоправданно
В частности, можно было, например, реализовать как-то привязку одной из двух реализаций к списку типов, совсем немного продублировав код. Очень может быть, что так будет значительно проще, чем с mpl
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>1. Видел в проекте (благо не в моём) самопальный умный указатель — зрелище достаточно убогое. Часть состояния открытая. Не защищён от большинства неправильных использований. Не обеспечивает безопасноть относительно возникновения ошибок. И т.д.
Согласен, но мне кажется, что часть таких ошибок некритична, (скажем защита от плохого использования не всегда нужна), а часть происходит от общей низкой квалификации. Но в любом случае умный указатель -- это довольно древняя идея. И мне кажется, что она не идея А. Во всяком случае есть много реализаций умных указателей, которые вовсе не являются продвинутыми шаблонами. R>2. Видел много примеров плохого дизайна, когда люди не разделял ортоганальные аспекты. А валили всё в одну большую кучу.
Плохого дизайна я видел часто много. Но вот именно от того, что они не применили Loki я что-то ещё не разу не пожалел
Хотя я согласен, что размышление над книжклй в целом полезно. Но рамышление должно быть направлено в правильную сторону. Не "как бы этоприменть?", а "где бы это могло бы упростить код?"
R>Дело не именно в А. Дело в том, что люди пытались делать все очень просто, как в лабораторной в институте. Я бы даже сказал наивно. Со временем это аукалось.
Это ясный пень что аукнется. Навернео они ещё и проетированием своих изделей не занимались...
R>>>Если только наличие требуемого поведения, то тогда конечно любую задачу можно решить очень просто... E>>Сопровождение и развитие ещё требуется.
R>Сопровождение и развитие — это относится к проекту, а касательно кода? Т.е. какие требования к коду, что бы проект был сопровождаемым и развиваемым?
Это отдельная долгая тема. В целом можно рассматривать такое свойство кода, как сопровождаемость и возможность переиспользования.
Ну типа сколько в среднем занимает что-то сделать с кодом. Чем сумма меньше, тем сопровождаемость больше
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
E>>Ну в целом подход похвальный. Но есть две беды. E>>1) Очень уж неудобный язык описания моих желаний R>Есть немного. Покрайней мере непривычный.
E>>2) Компилятору-то я может и объясню, но лучше бы объяснять тому, кто будет этот код поддерживать R>В чём проблема?
смотри пункт 1
В целом проблема в том, что язык выражения желаний крайне непрям. Соответсвенно восстановление их из записи тоже небанально
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень . А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Erop, Вы писали:
E>>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.
I>И в большинстве случаев лучше на Java, а не на C++.
Да, так точно — все должно быть примерно просто и без лишних наворотов. А к тому же лучше всего было бы не писать один и тот же код по сотне раз, для чего в С++ и были введены шаблоны: C++ STL лучшее этому доказательство. А если при этом плевать на используемые ресурсы, то как нельзя лучше подойдет нечто вроде Java.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Anton V. Kolotaev, Вы писали:
E>>>Казалось бы граф. движок не должне быть сверхсложен архитектурно. AVK>> Интересно, на чем основано это мнение?
E>Ну, скажем так, он дожен быть намного проще ОС, например.
В нектором роде, он и есть замена OC
Особенно движок типа небулы, который не просто графический движок, а скорее портируемый
framework для игр.
E>Нет? Возможно я неправильно понгимаю, что скрывается за словми "графический движок"
Не знаю об опыте использования именно Loki, но вот об ОЧЕНЬ успешным опытом внедрения его идей я пользуюсь почти в каждом проекте.
Это ATL.
Кто не верит — смотри в исходники. Самый простой пример стратегии в ATL — DefaultThreadTraits. Используется как параметр шаблона CThreadPool.
Вот так вот ...
Здравствуйте, remark, Вы писали:
A_A>>>>>Поэтому нужен баланс между простотой и универсальностью решения. E>>>>Конечно, просто мне кажется, что в STL баланс неоправданно смещён в сторону универсальности. Вот, скажем, в каких языках было нужно реализовывать алгоритм merge в библиотеке? R>>>А какие ещё языки предназначены для создания библиотек? E>>Ну, скажем дельфи R>Нет
Как так нет? Разве дельфи не славится своим "компонентным программированием"?
E>>Но вообще библиотек я знаю вообще много на каких языках. Скажем на fortran. E>>А вот стандартная библиотека, или какое-то её подобие есть вообще практически во всех языках R>Отношения к делу не имеет. В прикладном языке и стандартная библиотека соответствующая.
Очень хорошо. Где есть merge-то?
E>>А merge я вот что-то не припомню. Видимо не было на него пока что спроса всё-таки R>Это языки совсем другие.
В чём другие? Какие такие задачи часто решают на C++ с продвинутыми шаблонами, что merge нужен, а в других языках не нужен?
R>Твоя цитата: R>
R>так что я с радостью выбросил бы и итераторы и отсутсвие проверок в самом частотном доступе к элементу и т. д.
R>Советую почитать Страуструпа про язык с++. Ты сейчас предложил примерно следующее "А давай в java введём ассемблерные вставки".
-1
И за этот совет спасибо. Но он немного запоздал. Да и аналогия мне не ясна.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, FR, Вы писали:
E>>>>Казалось бы граф. движок не должне быть сверхсложен архитектурно. AVK>>> Интересно, на чем основано это мнение?
E>>Ну, скажем так, он дожен быть намного проще ОС, например.
FR>В нектором роде, он и есть замена OC FR>Особенно движок типа небулы, который не просто графический движок, а скорее портируемый FR>framework для игр.
E>>Нет? Возможно я неправильно понгимаю, что скрывается за словми "графический движок"
FR>наверно
Ну, тем не меее, в ОС пока что как-то неплохо выходило обходиться без шаблонных наворотов
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Kapone, Вы писали:
K>Не знаю об опыте использования именно Loki, но вот об ОЧЕНЬ успешным опытом внедрения его идей я пользуюсь почти в каждом проекте. K>Это ATL. K>Кто не верит — смотри в исходники. Самый простой пример стратегии в ATL — DefaultThreadTraits. Используется как параметр шаблона CThreadPool. K>Вот так вот ...
Я согласен, что ATL не так уж плоха, кстати. Но всё-так тоже несколько переусложнено там всё.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>2) Под OS Linux если вы пишете библиотеку или даже SB-шку, всем компонентам доступны все символы. E>Это приводит к тому, что если в двух частях программы используются разные реализации STL, то всякие приватные шаблонные потроха начинают конкурировать по именам. Нарушается ODR собственно говоря. А так как нарушители шаблонные, то линкер это дело пропускает. E>Так что какие-то случайные места проекта от сборки к сборке (или даже от загрузки к загрузке) начинают сбоить из-за того, что в данном конкретном месте взялась не та версия потрохов.
E>Поддерживать такое -- просто мечта поэта. Без работы, во всяком случае, точно не останешься
Легкий оффтопик: данная проблема не имеет ничего общего с шаблонами, строго говоря. Пересечение динамических имен может случится и на обычных функциях. Назвали два чувака в разных библиотеках функцию getRecordCount одинаково — и добро пожаловать в gdb. Решается с помощью version scripts для дисциплинированных или при помощи опции линкера -Bsymbolic для ленивых.
It's kind of fun to do the impossible (Walt Disney)
E>Собственно у меня к тебе личная просьба. Если такой пример вдруг отыщется, то сообщи о нём нам всем. Ладно?
Предлагаю не пример, а небольшую задачку. Очень часто при разработке и проектировании встречается следующая задача — есть некий объект-источник событий, и есть подписчики на эти события. При возникновении события объект уведомляет о нем своих подписчиков. С помощью критикуемых вами технологий организация такого взаимодействия решается достаточно просто — с использованием библиотек boost::function и/или boost::signal + boost::bind решение займет три строчки. При этом ни на на подписчиков событий, ни на источник оных не будет накладываться никаких существенных ограничений при минимальном уровне связности кода. Как подобную задачу решают у вас без приминения оных "изысков"?
Не умножай количества сущностей сверх необходимого
Здравствуйте, Alex Alexandrov, Вы писали:
AA>Легкий оффтопик: данная проблема не имеет ничего общего с шаблонами, строго говоря. Пересечение динамических имен может случится и на обычных функциях. Назвали два чувака в разных библиотеках функцию getRecordCount одинаково — и добро пожаловать в gdb. Решается с помощью version scripts для дисциплинированных или при помощи опции линкера -Bsymbolic для ленивых.
Расскажи поподробнее, как это всё поможет при наличии таки двух реализаций STL в проекте?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Flex Ferrum, Вы писали:
FF>Ок. Тогда конкретнее. Возьмем типичный пример — форма и набор контролов. Контролы уведомляют форму о происходящих в них событиях. Кнопка — вызовом метода void OnClick(), editbox — void OnTextChange(const char* newText), listbox — void OnSelChange(int oldItem, int newItem);
ИМХО это стандартная задача и есмть много станадртных решений. Одно из самых простых -- задавать события идентификаторами и иметь мапинг из идентификаторов в массив обработчиков или методов, что удобнее. Что-то типа MFC-way
Всё красоты boost'а ничего особенно нового не добавляют в это дело. Кроме всяких формальных свобод. Вроде того, что можно повесить на кнопку формы сразу функцию KillProcess, а не писать для этого специальный метод-обработчик из одной строки
Лично мне больше нравится таки подход, когда отображение событий на функции задаётся как-то формально, а все обработчики являются методами какого-то класса. Скажем методами той самой формы.
Поддерживать проще как-то получается
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, rm822, Вы писали:
R>Было несколько некрофилов , компания egartech.ru R>Люди восприняли проект как свою личную песочницу и поюзали всю мощь Loki до какой смогли добраться. R>А там где Loki не хватило или там где имена были слишком длинныим обильно склеили соплями макросов. R>Использовать макросы они стеснялись не больше чем Loki, я даже подозреваю что они их ЛЮБИЛИ R>Сомневаюсь что кто-то может представить ЧТО получилось ЭТО надо видеть.
Проекты написанные в стиле old-C тоже, знаешь, бывают "произведениями искусства"
Макросы там тоже, кстати, некоторые очень любят.
Суть не в шаблонах и не в макросах, суть, имхо, глубже. Шаблоны и макросы — средства.
Тут вот, например, есть один товарищь (не будем называть имён ), который пишет темы типа ручного создания аналога таблицы виртуальных функций с динамичискими временными замещениями ряда функций, и с поддержкой copy-on-write... Бррр. Мурашки по коже бегут
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, remark, Вы писали:
R>>А есть программисты, которые сразу считают for_each — сакс, я его ни разу не применял, но всё равно это сакс. CC>Тот for_each который в STL — тот сакс, ибо писать функтор для каждого чиха неудобно CC>BOOST_FOREACH гораздо удобнее
Ну вот про это я и говорил. Ты знаешь и понимаешь чем for_each сакс. И чем BOOST_FOREACH не сакс
Здравствуйте, Аноним, Вы писали:
А>Что значит "механизм распространения и перехвата исключений" — средства ОС + их использование компилятором? Как это выглядит в ассемблере?
Кстати ничего сложного и для C++-программиста очень полезно
Здравствуйте, remark, Вы писали:
R>Здравствуйте, rm822, Вы писали:
R>>Было несколько некрофилов , компания egartech.ru R>>Люди восприняли проект как свою личную песочницу и поюзали всю мощь Loki до какой смогли добраться. R>>А там где Loki не хватило или там где имена были слишком длинныим обильно склеили соплями макросов. R>>Использовать макросы они стеснялись не больше чем Loki, я даже подозреваю что они их ЛЮБИЛИ R>>Сомневаюсь что кто-то может представить ЧТО получилось ЭТО надо видеть.
R>Проекты написанные в стиле old-C тоже, знаешь, бывают "произведениями искусства" R>Макросы там тоже, кстати, некоторые очень любят. R>Суть не в шаблонах и не в макросах, суть, имхо, глубже. Шаблоны и макросы — средства.
R>Тут вот, например, есть один товарищь (не будем называть имён ), который пишет темы типа ручного создания аналога таблицы виртуальных функций с динамичискими временными замещениями ряда функций, и с поддержкой copy-on-write... Бррр. Мурашки по коже бегут
R>Макросы на пару экранов тоже приходилось видеть
R>
Речь шла о примерах реального применения Loki
"-Доктор я умру?
— А как же!.. Лет через 30-40 если будете соблюдать умеренность в еде и питье
" (c)
В данном случае люди попав за шведский стол попытались скушать ВСЕ
Не важно что они кушали, шаблоны, макросы или С-функции с GlobalVar-ами, важно что умеренность и совместимось не соблюадась — НО это И ТАК ПОНЯТНО любому ежику
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень . А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Х. Дейтел, П. Дейтел. Все понятно, доходчиво, структурировано. Кул и маст хэв.
Здравствуйте, Erop, Вы писали:
E>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет
Не Prolog только конечно, а LISP. LISP — это "отец" функционального и обобщенного программирования.
Здравствуйте, Alex Alexandrov, Вы писали:
AA>Может быть и доступно пониманию ребенка СЕЙЧАС, но надо иметь в виду, что "Паттерны" Банды Четырех были выпущены в 1995 году, а написаны еще раньше. В то время многие в этой стране и не задумывались о том, что такое Наблюдатели, Посетители, Фабрики и прочее. Как никак этим идеям уже почти 12 лет, так что восхищаться и бить себя кулаком в грудь по поводу паттернов как-то глупо. Это просто классика, общий язык — и его надо знать.
Паттерны во многом по идеям Коплиена написаны... А он свою книжку выпустил в 1992 году.. Значит, думал — еще раньше...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, MasterZiv, Вы писали:
E>>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет
MZ>Не Prolog только конечно, а LISP. LISP — это "отец" функционального и обобщенного программирования.
Это тут где-то уже обсуждалось и даже спорили. Не могу найти.
В принципе обе версии имеют шансы, но на пролог похоже таки больше
Ну просто обратное сопоставление шаблонов функций больше похоже на вывод теорем в прологе, чем на лисп
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>Ну я надеюсь, что он хотя бы типобезопасный, а не на void* работает R>И ещё надеюсь, что мне, что бы захранить в таком контейнере какой-то класс, не надо вначале реализовывать интерфейс IStorable
Спасибо за то, что надеешься, что у нас всё хорошо
И это так. Всё хорошо и довольно удобно. Лично мне нравится не всё, но намного лучше, чем stl::vector
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Quasi!
А ты не веришь что у кого-то получится?
Или что получится не у всех?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, creatman, Вы писали:
R>>>Я совершенно согласен, что мультиметоды вещь достаточно редкая, поэтому к ним такое и отношение. Но А тут совершенно ни при чём. Он лишь предложил достаточно хорошую реализацию мультиметодов. Но в том, что это редкая вещь, он не виноват. E>>Крнечно не виноват! Это его заслуга, что он смог придумать столь редкую задачу и решение для неё. Просто вся эта штука очень далека от реальной жизни E>>А виноват чувак, который решает внедрить мультиметоды туда, где они не нужны. Потому что так "покруче" будет
C>Назначение мультиметодов помоему хорошо описаны у Саттера (Правило 31 кажется). Я их лично использовал для реализации физики при разработке движка игры.
Поправка: не у Саттера а у Майерса (Наиболее эффективное использование C++). Там как раз раскрывается тема коллизии динамических объектов в компьютерных играх. На сколько мне не изменяет память, Александресску ссылался в своих мульти методах на Майерса и от себя добавлю, что А привел более удачное решение проблемы.
Здравствуйте, creatman, Вы писали:
C>Поправка: не у Саттера а у Майерса (Наиболее эффективное использование C++). Там как раз раскрывается тема коллизии динамических объектов в компьютерных играх. На сколько мне не изменяет память, Александресску ссылался в своих мульти методах на Майерса и от себя добавлю, что А привел более удачное решение проблемы.
Типа для выбора обработчика столконовения?
Что будет, если пуля типа 8 попадает в монстра типа 13?
В принципе я соглачен, что там мультиметоды могут быть уместны.
Правда у меня в анологичной задаче (правда не из области игрушек ) было не совсем так.
Было так, что есть пара типовых реакций. И есть ещё штуки три нетиповых.
Соответсвенно хорошо получается с двойной диспечеризацией, что довольно похоже на мультиметоды, в принципе, но и с if'ами в таком раскладе всё выгляди т не особо плохо.
Скажем в моей задаче, если продолжать аналогию, большинство монстров реагирует на столкновене с пулей одинаково, есть один монстр, который на пулю № 7 реагирует особо и есть одна пуля № 12, которая совсем иначе сталкивается с каждым из монстров.
Ну и соответсвенно в обработчике стокновения с пулей № 7 стоит if на тип монстра, и специальная обработка на эту тему, и в обработчике столкновения с пулей № 12 стоит двойная диспечерезация (у монстра вызывают метод ProcessBullet12 )
Смысл в том, что все обработчики просто ищутся. Всё, что нужно знать про эту конструкцию, это то, что столкновение обрабатывает пуля.
Хотя, конечно, и мультиметоды тут были бы более или менее уместны, просто слегка сложнее бы всё смотрелось.
Если бы, скажем, пуль, вроде пули №12 было бы побольше, то я бы, пожалуй и не спорил. Но вот такой задачи так и не возникло
(На самом деле задача совсем другая, чем игры. Типа процесс сопоставления одной из можеделей из списка с разными объектами. Некий перебор AI-гипотез, короче говоря)
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, creatman, Вы писали:
C>>Поправка: не у Саттера а у Майерса (Наиболее эффективное использование C++). Там как раз раскрывается тема коллизии динамических объектов в компьютерных играх. На сколько мне не изменяет память, Александресску ссылался в своих мульти методах на Майерса и от себя добавлю, что А привел более удачное решение проблемы.
E>Типа для выбора обработчика столконовения? E>Что будет, если пуля типа 8 попадает в монстра типа 13?
E>В принципе я соглачен, что там мультиметоды могут быть уместны. E>Правда у меня в анологичной задаче (правда не из области игрушек ) было не совсем так. E>Было так, что есть пара типовых реакций. И есть ещё штуки три нетиповых. E>Соответсвенно хорошо получается с двойной диспечеризацией, что довольно похоже на мультиметоды, в принципе, но и с if'ами в таком раскладе всё выгляди т не особо плохо.
Двойная диспетчеризация — есть способ реализации мультиметодов. Так же как switch-on-type есть способ реализации динамического полиморфизма.
Если есть 2 или более типов и код, который необходимо выполнить, зависит от этих типов, то это мультиметод. По определению. А как их реализовывать — это уже другой вопрос. С помощью if'ов, двойной диспетчеризации, шаблонных наворотов, или с помощью поддержки в языке.
Здравствуйте, remark, Вы писали:
R>Двойная диспетчеризация — есть способ реализации мультиметодов. Так же как switch-on-type есть способ реализации динамического полиморфизма. R>Если есть 2 или более типов и код, который необходимо выполнить, зависит от этих типов, то это мультиметод. По определению. А как их реализовывать — это уже другой вопрос. С помощью if'ов, двойной диспетчеризации, шаблонных наворотов, или с помощью поддержки в языке.
Я как бы писал про то, что если сотавить матрицу, где по вертикали отложить типы пули, по горизонтали типы монстров, а в клетку -- обработчик, то в задачах, которые я встречал вообще, эта матрица была очень сильно вырожденной.
Ну типа там почти во всех клетках был дефолтный какой-то обработчик, и какой-то столбик или строка были заполнены.
Ну и ещё где-то в нескольких местах были другие обработчики.
Собственно мне кажется, что специальная сложная реализация этой матрицы, которая умеет делать всё хорошо для случая невырожденной матрицы, оказывается излишней в случае вырожденной. Про это речь собсвтенно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Двойная диспетчеризация — есть способ реализации мультиметодов. Так же как switch-on-type есть способ реализации динамического полиморфизма. R>>Если есть 2 или более типов и код, который необходимо выполнить, зависит от этих типов, то это мультиметод. По определению. А как их реализовывать — это уже другой вопрос. С помощью if'ов, двойной диспетчеризации, шаблонных наворотов, или с помощью поддержки в языке.
E>Я как бы писал про то, что если сотавить матрицу, где по вертикали отложить типы пули, по горизонтали типы монстров, а в клетку -- обработчик, то в задачах, которые я встречал вообще, эта матрица была очень сильно вырожденной.
E>Ну типа там почти во всех клетках был дефолтный какой-то обработчик, и какой-то столбик или строка были заполнены. E>Ну и ещё где-то в нескольких местах были другие обработчики.
E>Собственно мне кажется, что специальная сложная реализация этой матрицы, которая умеет делать всё хорошо для случая невырожденной матрицы, оказывается излишней в случае вырожденной. Про это речь собсвтенно
Матрица здесь действительно возможно не к месту. Ну а причём здесь матрица?
Имхо адекватная реализация мультиметодов должна быть как реализация просто виртуальных методов. Когда у тебя есть дефолтная реализация в базовом классе. А где надо ты её перекрываешь.
И для твоего примера с пулями подходит хорошо. Т.е. делаешь дефолтную реализацию. И перекрываешь для пули №7 и монстра №18. И для пули № 21 и всех монстров.
Здравствуйте, remark, Вы писали:
R>Матрица здесь действительно возможно не к месту. Ну а причём здесь матрица? R>Имхо адекватная реализация мультиметодов должна быть как реализация просто виртуальных методов. Когда у тебя есть дефолтная реализация в базовом классе. А где надо ты её перекрываешь. R>И для твоего примера с пулями подходит хорошо. Т.е. делаешь дефолтную реализацию. И перекрываешь для пули №7 и монстра №18. И для пули № 21 и всех монстров.
Так бы, возможно, было бы удобно
Но весь вопрос в деталях. Увы. Пока никак нельзя, только через меганавороты
R>
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, creatman, Вы писали:
C>Ну если мне не изменяет память Александресску обозначил двойную диспечерезацию как частный случай мультиметодов. Конечно в личном опыте не приходилось делать тройную и более диспечерезацию, но возможно в каких-то научных областях это могло бы пригодиться. Например можно пофантазировать на тему, как написать симулятор столкновения частиц в ядерном реакторе. Какие архитектурные решения можно тут применить и на сколько оправданно можно использовать мультиметоды Александресску
Упаси тебя Бог применять в этой задаче мультиметоды!
Никогда не сосчитается
Такие задачи обычно считают так, что заводят какое-нибудь пространство и в нём дефуры и их эволюция типа по сетке, возможно адаптивной
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Юрий!
А ты с чем собственно не согласен? С тем что мне что-то не встречалось или встречалось на практике?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Мне кажется это очень плохой пример , исключения являются очевидным механизмом , для разработчиков которые вручную делали обработку ошибок в большой системе.
К тому же кода становиться чуть ли не в 2 раза меньше, что облегчает чтение .
Т.е. использовать исключения НАМНОГО легче чем коды возврата.
)) 
"Всё что не убивает нас, делает нас сильнее..."
Реально сложные вещи- алгоритмы и логические задачи. В С++ и шаблонах/паттернах/whatever ничего сложного нет.
