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

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

КЛ>>Захотелось сделать так. А насколько это оправданно?... Просто тогда мне показалось это более целесообразным. Может быть завтра я посмотрю на тот код и удивлюсь, зачем я так сделал.


E>Ну в общем "и так каждый раз" (с) известный анекдот.

Тебе всегда нравится код, который ты писал полгода назад?

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

КЛ>Тебе всегда нравится код, который ты писал полгода назад?

Константин! Я же не говорю, что ты мегакривой проект реализовал
Я говорю, что если бы ты сразу не стал с визитором связываться, то было бы и лучше и проще и при следующем рефакторинге всё равно выбросишь

Мы же обсуждали хорошо ли стало кому от визитёра, например.

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

А так нормально всё. Но я так понял, что визитёр там был таки с горяча?

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

КЛ>Почти. Есть комбик для выбора текущего айтэма. Есть 2 кнопки, которые грэются в зависимости от него. Есть группа радиобаттонов, которые тоже могут грэиться. Есть листвью. В общем, все контролы общие, и я даже не думал делать это через ps. Кроме того, как ты стал бы выбирать, какой ps показывать? Опять же, либо if'ы, либо vf'ы, либо visitors. Надеюсь, теперь понятно?

Я бы сделал map из типа item'а в страничку.

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

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

КЛ>>Тебе всегда нравится код, который ты писал полгода назад?

E>Константин! Я же не говорю, что ты мегакривой проект реализовал
E>Я говорю, что если бы ты сразу не стал с визитором связываться, то было бы и лучше и проще и при следующем рефакторинге всё равно выбросишь

нет, все работает и выглядит неплохо

E>Мы же обсуждали хорошо ли стало кому от визитёра, например.

мне стало)))

E>А так не всегда. Правда мне обычно не нравится уже на след. день
E>Так что стараюсь сделать так, чтобы через полгода не испугаться ещё больше.

+1

E>А так нормально всё. Но я так понял, что визитёр там был таки с горяча?

50/50

С одной стороны можно было обойтись if'ми, с другой код стал более строже

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

E>>А так нормально всё. Но я так понял, что визитёр там был таки с горяча?
КЛ>50/50
КЛ>С одной стороны можно было обойтись if'ми, с другой код стал более строже

Ну скажем так, что этот пример меня не убедил
Мне кажется, что место вообще простое, понятное, и какой визитор не привенти -- сильно не испортишь, но в принципе без визитора проще

Хотя для "потренироваться" полигон выбран грамотно

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

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

E>>>А так нормально всё. Но я так понял, что визитёр там был таки с горяча?
КЛ>>50/50
КЛ>>С одной стороны можно было обойтись if'ми, с другой код стал более строже

E>Ну скажем так, что этот пример меня не убедил
E>Мне кажется, что место вообще простое, понятное, и какой визитор не привенти -- сильно не испортишь, но в принципе без визитора проще

проще. Но не значит лучше )

E>Хотя для "потренироваться" полигон выбран грамотно

+1

Здравствуйте, 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&amp;only=1

Автор: Chipsеt
Дата: 16.04.06

E>При этом соображения о том, что "все сложности под капотом" не многое тут меняет. Потому что эти все сложности с нами. Мне и std::vector не нравится потому, что он заради довольно простой функциональности, рожает нереально много всяких сложных довесочков. И от них нельзя просто отказаться.
E>Я бы, например, предпочёл, чтобы возможность использования алгоритмов подключалась в stl по явному требованию. А не была намертво в него вцементирована всегда.
так алгоритмы подключаются через #include <algorithm> явно
Это во-первых, а во-вторых, конкретно к вектору это никакого отношения не имеет, сам знаешь, алгоритмы работают на уровне итераторов (аналог указателей).

E>Потому что каждый раз, когда где-то, как правило в каком-то неудачном коде написанным невнимательным новичком, портится память, так я попадаю мордой под этот капот.И вынужден там ковыряться.
Аналогично и с "голыми" указателями. Но, по моему опыту, неправильное использование голых указателей отследить сложнее.

E>И при этом пользы-то никакой от наворотов я не получаю. Получаю гемор, поучаю догую компиляцию, получаю причудливую зависимость от версий компиляторов и библиотек и много чего ещё "хорошего".
Эту всю радость ты получишь абсолютно с любой библиотекой. Мне, по крайней мере, еще не попадались библиотеки, у которых никогда не было бы проблем при переходе с версии на версию компилятора (не говоря уже о смене компилятора с SunCC на GCC, скажем). И тем масштабнее проблемы, чем больше разница версий. А уж о том, как разные версии разных библиотек друг с другом уживаются — не сыпь соль на рану.

E>А вот реально хорошего от этой всей сложности получаю мало. Потому что все "выгоды", заради которых всё так непросто, они мне не нужны. И я не думаю, что потому, что я учавствую в разработке слилшком простых программ.
У меня эмпирический закон примерно такой: сложность кода определяется задачей, и только.
Если ты для решения сложной задачи используешь простые вещи — ты получишь огромный и сложный код.
Если ты используешь навороченные библиотеки — твой код будет простым (если это не так, либо ты неправильно эту библиотеку используешь, либо она неправильно спроектирована).
Грубо говоря, можно подключить libjpeg, а можно написать кодек самостоятельно прямо в production коде.
Суммарная сложность останется примерно той же.
Отсюда простая мораль: использование [правильно спроектированных] сложных вещей должно быть простым.
Чтобы в случае неправильной работы сразу было видно, в чем причина — в библиотеке или в твоем коде (STL в этом смысле, например, не идеал: одна возня с удалениями элементов контейнеров по итераторам чего стоит. Могли бы и предусмотреть сразу чего-нть на эту тему).

E>Я ещё раз призываю рассказать где же оно всё бывает нужно-то?
Ну уже сказал. В "Прикладных вопросах" был топик про реальное использование boost::mpl — посмотри еще там.
У меня лично сколь-нибудь нетривиальное использование шаблонов в основном сводится к traits, большего сановский компилятор просто не позволяет.

You will always get what you always got
  If you always do  what you always did

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

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

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

КЛ>Откуда такая информация? Каких виртуальных функций?
КЛ>Упрощенный смысл визитора в том, что он позволяет статически выбирать тип объекта с помощью динамического механизма. Т.е. выбор типа объекта, с которым будем работать, делает сам объект, статически.

http://www.gamedev.ru/community/oo_design/articles/?id=12
напрмиер

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

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


Я так понимаю все ваши проблемы от того что вы работаете в команде и ваш код пользуют
другие программеры.
Мне в этом отношении проще — пишу все проекты от начала и до конца , поэтому
грамматику использую по настроению
В принципе предпочитаю raw код — думаю что его проще просматривать и отлаживать
шаблоны пришлось использовать один раз — но я не жалею
Это конечно не подразумевает использования STL или того же CArray из
MFC , (котрый люблю и уважаю (MFC) ), а именно написание своих шаблонов.
Исключения практически не использую — толко коды возврата -NULL для
возврата указателей -1 в основном для другого.
Честно говоря с трудом представляю нынешнее программирование без
использования STL и иже с ним.
И хотя сам предпочитаю raw программирование , и думаю что такого должны придерживаться все
(вчера читал у Майерса чьето высказывание (может его) "Нужно писать просто насколько
возможно ,но не более"(хотя вроде это был Шекспир)) ,но знать все возможные методы
решения задачи никогда не помешает, ибо что для одного raw для другого "огого!!".
Ладно пора работать , а то у меня тут такой чужой код висит, что периодически
забываешь что это вообще может быть программой

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

M>(вчера читал у Майерса чьето высказывание (может его) "Нужно писать просто насколько
M>возможно ,но не более"(хотя вроде это был Шекспир))

Пусть это будет просто: 
просто, как только можно, 
но не проще. 

© А. Эйнштейн

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

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

M>>(вчера читал у Майерса чьето высказывание (может его) "Нужно писать просто насколько
M>>возможно ,но не более"(хотя вроде это был Шекспир))

E>

E>Пусть это будет просто: 
E>просто, как только можно, 
E>но не проще. 

E>© А. Эйнштейн
E>

точно но суть я думаю передал правильно

Ну вот те на. А я то думал, что иронию данного в форуме по C++ совета программировать на Java не заметить будет трудно.

Хорошо, открытым текстом: Ощущающим непреодолимую потребность в опрощении вряд ли стоит продолжать программировать на C++.

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

I>Ну вот те на. А я то думал, что иронию данного в форуме по C++ совета программировать на Java не заметить будет трудно.
Ну иногда у людей бывает ценность "написать программу которая делает то-то и то-то", а иногда даже и ценность "сделать то-то и то-то, а для этого написать программу такую и растакую. И часто так бывает, что для написания программ удобно использовать C++
А бывает, что люди пишут что угодно и как угодно (например максимально сложно), лишь бы на C++. Вторые наверняка оценили твою иронию

I>Хорошо, открытым текстом: Ощущающим непреодолимую потребность в опрощении вряд ли стоит продолжать программировать на C++.
Не менее открытым текстом: Людям, которые испытывают потребность в самоутверждении путём написания мегакрутых и сложных версий устаревшей и слишкомп понятной программы "Hello World" стоит сменить C++ на что-нибудь менее простое и более непонятное.

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

E>... стоит сменить C++ на что-нибудь менее простое и более непонятное.


Так ведь нет ничего такого...

Здравствуйте, 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&amp;only=1

Автор: Chipsеt
Дата: 16.04.06

Да я знаю. Я скромно считаю, что мы с ним единомышленники. И что 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

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

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

E>>... стоит сменить C++ на что-нибудь менее простое и более непонятное.


I>Так ведь нет ничего такого...

[url =http://en.wikipedia.org/wiki/Malbolge]Malbolge[/url]?

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

J>Здравствуйте, Erop!

J>Erop, дело в том, что Александреску подходит к проектированию как разработчик библиотеки общего назначения, которая будет потом использоваться в реальном прикладном коде, а ты мыслишь сразу категориями прикладного кода.
J>А у этих двух подходов принципиально разные задачи. У библиотечного — дать нечто максимально гибкое, всеобемлющее и удобное, чтобы его можно было заюзать при создании своего прикладного кода, а у прикладного — решить конкретную узкую и обычно простую задачу максимально простым и ясным способом.

[skip]

J>А то, что ты пишешь про прикладной код — это все правильно и я с этим полностью согласен.


Мысль, конечно правильная. Но. Мне лично достаточно жалко программиста (команду), который при работе с проектом порядка десятков/сотен тысяч строк кода на с++ не использует никакой инфрастуктуры/фреймворка для проекта, а прямо так и шпарит тысячи строк простого raw кода каждый день, который при возникновении любой проблемы в коде решает её здесь и сейчас самым простым способом... а завтра опять решает её в другом месте, а послезавтра опять решает её в другом месте. А потом в один прекрасный день встаёт необходимость чуть-чуть изменить решение этой проблемы....

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

И эту библиотеку тоже придётся поддерживать вместе с проектом. Т.ч. дублирование не умесно. А в с++, к сожалению, только самые примитивные виды дублирования можно устранить с помощью обычных функций. Если можно с помощью функции, то я конечно не против такого простого решения. Но часто просто не получается с помощью функции. Часто только ОО-подходы могут устанить дублирование. А часто и ОО-подходам это не под силу, тогда как-раз шаблоны и приходят на помощь (заметьте речь идёт о прикладном проекте). А иногда и шаблонам не под силу устранить дублирование, ну уж тогда на помощь приходят всеми нами любимые макросы.

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

R>И эту библиотеку тоже придётся поддерживать вместе с проектом. Т.ч. дублирование не умесно. А в с++, к сожалению, только самые примитивные виды дублирования можно устранить с помощью обычных функций. Если можно с помощью функции, то я конечно не против такого простого решения. Но часто просто не получается с помощью функции. Часто только ОО-подходы могут устанить дублирование. А часто и ОО-подходам это не под силу, тогда как-раз шаблоны и приходят на помощь (заметьте речь идёт о прикладном проекте). А иногда и шаблонам не под силу устранить дублирование, ну уж тогда на помощь приходят всеми нами любимые макросы.

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

Но это всё не про книжку А.
Там предлагаются навороты, которые ИМХО ни в каком реальном проекте не пригодятся

пример однозначно неоправданной сложности

Автор: Андрей Коростелев
Дата: 19.04.06

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

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

R>>И эту библиотеку тоже придётся поддерживать вместе с проектом. Т.ч. дублирование не умесно. А в с++, к сожалению, только самые примитивные виды дублирования можно устранить с помощью обычных функций. Если можно с помощью функции, то я конечно не против такого простого решения. Но часто просто не получается с помощью функции. Часто только ОО-подходы могут устанить дублирование. А часто и ОО-подходам это не под силу, тогда как-раз шаблоны и приходят на помощь (заметьте речь идёт о прикладном проекте). А иногда и шаблонам не под силу устранить дублирование, ну уж тогда на помощь приходят всеми нами любимые макросы.

E>да всё таки и есть в целом.
E>Только прикольно, что в качестве крайнего средства предлагаются не шаблонные шаблонные параметры, как у А., а макросы

Я объяснил почему — некоторые виды дублирования подвласны только им.


E>Но это всё не про книжку А.
E>Там предлагаются навороты, которые ИМХО ни в каком реальном проекте не пригодятся


Ну я уже понял, что ты научился очень быстро набирать/править код (здесь

Автор: Erop
Дата: 19.04.06

). Я лично не достиг такого мастерства, мне лично не нравится дублирование, поэтому я готов менять часть простоты кода на устранение дублирования.

Некоторые виды дублирования нельзя устранить ни какими способами, кроме advanced-templates (не считая таких отстойных вещей как макросы и void*).

Моё обоснование использования advanced-templates в двух указанных выше предпосылках.

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

Идеальной внимательностью я кстати тоже не обладаю, поэтому не люблю, когда мне приходится "поправлять" десятки "почти похожих мест" в проекте.