Здравствуйте, 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>Здравствуйте, Аноним, Вы писали:

А>>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр.
А>>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .


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. Я Александреску читал, был в восторге. Однако на практике применить материал удаётся крайне редко. Так что можно особо не торопиться с современным программированием. Оно, как искуство каллиграфии, уходит в область, далёкую от практических задач.

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

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

[skiped...]
R>Не используем паттерны проектирования и сложную архитектуру, т.к. могут придти программисты не разбирающиеся в этом.
[skiped...]

Конечно не используем "сложную архитектуру" но применяем патерны. Задача патернов — упростить архитектуру а не наоборот.
хорошая архитектура == простая архитектура, самая простая которая решает поставленные задачи.

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

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


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'ы, фабрики и т.д.?

Да все фабрики самодельные. Редко бывают такие сложные задачи, что нужно автоматизировать написание фабрик

Здравствуйте, 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 прикрутить и сякой и тесты модульные наладить, то типа бкдт нам счастье. А я не понмаю зачем. Единственный заметный мне эффект -- разработка требует больше времени, более продвинутых, то есть дорогих, программеров и становиться труднее в отладке и поддержке. А плюсы-то какие?

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

КЛ>Если менее квалифицированный кадр чего-то не знает — это не повод не использовать это "чего-то". Могу сказать по собственному опыту — большой проект с большой текучкой программистов, которые не слышали про итераторы( причем тут А. не понимаю, он про них не пишет и не он их придумал.) — это самоубийство. И мне наплевать, слышали они про std::vector или нет, мне нужна надежная работающая программа и от std::vector из-за какого-то Васи(Феди...) я от него не откажусь, лучше от Васи(Феди...) откажусь, пусть технологии учит...

Я согласен с тобой, что от std::vector стоит отказываться только в случае если есть что-то лучше. Так как хуже уже точно опускаться не стоит.
Но вот от списков типов и от Loki я бы отказался однозначно во всех известных мне проектах.
Хотя "бы" тут даже лишнее. Пока что я во всех отказался

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

E>Здравствуйте, Константин Л., Вы писали:

КЛ>>Если менее квалифицированный кадр чего-то не знает — это не повод не использовать это "чего-то". Могу сказать по собственному опыту — большой проект с большой текучкой программистов, которые не слышали про итераторы( причем тут А. не понимаю, он про них не пишет и не он их придумал.) — это самоубийство. И мне наплевать, слышали они про std::vector или нет, мне нужна надежная работающая программа и от std::vector из-за какого-то Васи(Феди...) я от него не откажусь, лучше от Васи(Феди...) откажусь, пусть технологии учит...

E>Я согласен с тобой, что от std::vector стоит отказываться только в случае если есть что-то лучше. Так как хуже уже точно опускаться не стоит.
E>Но вот от списков типов и от Loki я бы отказался однозначно во всех известных мне проектах.
E>Хотя "бы" тут даже лишнее. Пока что я во всех отказался
Да я тоже их не использую, но это не значит что они сакс и нигде не пригодны. Если появится задача, при решении котрой они мне помогут, я буду их использовать.

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

КЛ>Если этого требует задача, и это решение проанализировано, то почему нет?

Ну приведи же наконец пример реальной задачи, где всё это великолепие нужно!
Я вот таких задач не знаю

E>>2) Во-вторых, эта книжка мне нравится потому, что там очень хорошо и на примерах описано насколько плохо программировать таким образом
КЛ>Сложно — бесспорно, плохо — смотря для чего.
Ну собственно пока что всегда удавалось писать проще. К чему бы это?

E>>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет
КЛ>А. тут ни при чем, шаблоны сами по себе сложны. Ты против А. или против шаблонов? Мне кажется 2-oe.
Ну вот шаблонный массив, особенно если без итераторов, константных итераторов, какими-нибудь аллокаторами попроще немного, без связанных аллокаторов и т. д. очень даже и хорош бывает. Но даже и std::vector вполне приемлем.
Но то, что делает с шаблонами А -- это точно совершенно в реальной жизни малоприменимо. Если тебе так не кажется, приводи примеры арихитектур и задач, где это таки нужно и хорошо.


E>>Но при этом не особо опытные инженеры этого всего не понимают и очень сильно переусложняют код.

E>>Так что очень может быть, что стиот почитать вские умные книжки на эту тему, особенно про паттерны проектирования, но главная идея должна быть такая, что никогда не забывать точно ли это нужно для реально возникающих в твоей деятельности задач.
КЛ>Золотые слова. Но если ты в своей деятельности не встречаешься с задачами, которые требуют применения таких извращений, это не значит, что другие не встречаются.

Ну вот я имею наглость утверждать, что я уже много чего повидал на почве программирования.
Приводи таки примеры задач, где фокусы от А. и Loki в частности полезны и нужны

E>>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.

КЛ>Я бы не был столь категоричным. Большинство того, что он там пишет можно и нужну использовать. Просто надо знать "что?где?когда?". Никто не говорит о использовании typelists в приложении на 20 .h/.cpp., которое кажет 1 диалог с 2-мя кнопками... Если я не ошибась, А. сам пишет о том, что нужно искать компромиссы, здравые решения для каждой конкретной ситуации.

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

Но я так и не понял согласен ли ты с выделенным?

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-объекты.

Списки типов генерируется с помощью Comet из TLB-файлов (
http://www.lambdasoft.dk/comet/index.htm ).

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

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) Мультиметоды (не юзаю, а ты? Пр. — низкая(ИМХО))

Кроме практической ценности эта книга имеет очень большую теоретическую ценность.

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

R>Да, но читать-то и знать всё это надо.
R>Энание и опыт не придёт никак иначе, кроме как через использование.

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

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

КЛ>1) Обощенные функторы (не использую, а ты? Применимость — хз, но думаю средняя)
Не использую.
КЛ>2) Реализация шаблона Singleton (В какой-то степени, а ты? Применимость — почти каждый юзает в том или ином виде)
Не использую. Мало того, считаю, что самая хорошая реализация синглетона -- это что-то типа:

class CMySingletonObject {
    //  тут что-то такое
};
extern CMySingletonObject MySingletonObject;

Иногда, но уже довольно редко, бывает и так, что в конструкторе синглетона инициализируют указатель этот единственный объект, и что-то такое проверяют assert'ами.
А делают это всё потому, что нужен

static CMySingletonObject* CMySingletonObject::Get()

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

КЛ>3) Интеллектуальные указатели (юзаю, а ты? то же, что и предыдущий)
Использую, но не такие сложные, как у А. Но шаблонные
НО конкретно в умных указателях, ИМХО, А. нисего нового и при этом полезного не сказал.

КЛ>4) Фабрики объектов (не изаю, нет необходимости. А ты? Применимость — имхо средняя)
Фабрики объектов иногда у меня бывают, но не очень часто. при этом они всегда сделаны по месту. Шаблонных наворотов нету
У нас в конторе есть одна шаблонная фабрика. РАдикально более простая, чем у А. кстати. Вернее фабрика не шаблонная, шаблонный регистратор типа объекта.

КЛ>5) Шаблон Abstract Factory (см. пред. пункт)
Не использую. Хотя, наверное то, что есть у нас в конторе, ближе сюда

КЛ>6) Шаблон Visitor (к своему сожалению юзаю в 1ом месте, а ты? Пременимость — пр. пункт)
Почему к сожалению и о чём именно ты сожалеешь? О том, что используешь или о том, что используешь один раз?
Мне известно о четырёх серъёзных попытках использовать этот шаблон. Все четыре провалились. То есть потом код был всё-таки переписан, без визитора и стал проще, лучше, понятнее и всё такое.

КЛ>7) Мультиметоды (не юзаю, а ты? Пр. — низкая(ИМХО))
Не использую и не верю, что может пригодиться

КЛ>Кроме практической ценности эта книга имеет очень большую теоретическую ценность.
++++1
С этим я никогда и не спорил
Мало того, я считаю, что читать её полезно, чтобы научиться смотреить на вещи и таким образом, но при этом надо пнимать, что целесообразность такой красоты красоты ты сможешь оценить только приобретя изрядного опыта, ну и должно понимать, что применять это всё скорее всего не надо.

А так да, согласен

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

C>Списки типов генерируется с помощью Comet из TLB-файлов (
C>http://www.lambdasoft.dk/comet/index.htm ).


ИМХО из TBL-файлов можно бы генирировать и что-то более понятное и удобное