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

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

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

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

КЛ>>Откуда такая информация? Каких виртуальных функций?
КЛ>>Упрощенный смысл визитора в том, что он позволяет статически выбирать тип объекта с помощью динамического механизма. Т.е. выбор типа объекта, с которым будем работать, делает сам объект, статически.
P>Ой как сказал. Я бы не понял, если бы не знал о чем речь . А я вот не использую visitor. Из прынцыпа. Я до сих пор использую двойную диспетчеризацию (в контексте, как она описана здесь), потому как считаю, что полезная содержательная суть визитора — это двойная диспетчеризация. Все остальное — это навороты и от лукавого. И в основном для того, чтобы дотянуть его до "паттерна проектирования". Поправьте меня, если я не прав.
Прочитал. Так паттерн визитор и есть двойная диспетчеризация, о которой я и написал.
А под "он позволяет статически выбирать тип объекта с помощью динамического механизма" я имелл ввиду это

class CCasino: public CBuilding
{
public:
     virtual void doDraw (CMap* map)
     {
        map->doDraw(*this);
     };
};

, т.е. уже на этапе компиляции выбирается метод doDraw

Typelist'ы из Loki применяются в Nebula-2 — open source графическом движке.

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

L>>>Почему же крайне отрицательно? Отнюдь, когда библиотека облегчает мне работу с предметной областью — то я двумя руками и двумя ногами за. Но тащить тот же boost::singleton к себе в проект ради чистоты концепции — увольте

A>>Отнюдь не ради чистоты концепции, а чтобы облегчить работу своим сотрудникам и освободить их от необходимости разбираться в самопальном синглтоне.

L>Да в чём там разбраться-то?? Сотрудники что — не знают что такое глобальные переменные?



>>>Благо, 90% всех синглтонов можно сделать на коленке описанным способом за 5 минут.

A>>У тебя даже объяснить это толком не получается, не говоря уже о том, чтобы сделать.

L>Правильно — вот это наш способ вести разговор. "Что может думать по этому поводу человек с лысиной и таким носом? Пусть сначала отрастит волосы, исправит нос — а потом высказывает своё мнение!"

Посмотри

Автор: Left2
Дата: 20.04.06

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

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

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

Вот здесь присоединяюсь.
На мой взгляд, этот паттерн — один из самых неудачных.
В нашем проекте он используется в паре мест — эта пара если не возглавляет список самых противных мест проекта, то в первой десятке держится уверенно.
Самая большая проблема этого паттерна — абсолютно нечитабельный код, получающийся в результате.
Т.е. доходит до того, что там, скажем, появится запрос на что-нть сделать, ты сидишь, два дня разбираешься, что вся эта гора кода делает и куда же тебе встроиться. Так вот проблема в том, что если через месяц придет на этот участок еще одна задача — тебе опять потребуется потратить 2 дня, потому что запомнить это невозможно — все выглядит абсолютно одинаково, и с первого двухчасового взгляда совершенно непонятно, как же все это работает — потому что код, который делает что-то реально, представляет собой указатель на что-то, что принадлежит указателю на что-то другое, и аргументами ко всему этому идут указатели на третье и четвертое, и проследить через цепочки вызовов, откуда же все эти указатели пришли и чему они реально соответствуют — мозги вскипят. А когда эти указатели начнут совокупляться в разных сочетаниях, при этом заходя то в дверь, то в окно....

А вторая проблема — это ригидность структуры (но это вообще беда большинства паттернов).
Суть в том, что паттерн призван решить задачу минимумом кода, так? Т.е. понятно, что нужную структуру взаимоотношений классовв можно задизайнить десятком различных способов, и выбор в пользу того или иного дизайна определяется в том числе и тем, насколько он позволяет вносить изменения в дальнейшем. Так вот паттерны в основном задают чрезвычайно жесткую структуру (особенно паттерны поведения, типа визитора), ориентированную на какой-то один предполагаемый вид изменений, при этом все остальные превращаются в ад для программиста.
Я прошел через это в качестве "объекта бесчеловечных опытов" несколько раз. Конкретная подсистема, о которой я поведу речь для примера, призвана древообразно выполнять некие операции над определенным множеством объектов (операции порождают множества примерно таких же объектов, к ним могут быть применены другие операции, и т.д, дерево операций задает пользователь), а на выходе получается опять плоский список объектов (т.е. промежуточная структура обработки теряется). Так вот, организация классов, вся из себя красивая на первый взгляд, на самом деле заточена исключительно под то, чтобы добавление новой операции было легким делом. И эта задача худо-бедно выполнена, потому что (ну и остальные проблемы до кучи, из тех, что навскидку вспомнились):

1. Легко (действительно легко, этого не отнимешь) добавлять только операции того же типа, что уже есть. Добавление операции, работающей принципиально иначе, практически невозможно.
   
2. Операциям доступны какая-то небольшая информация об объектах. Попытаться достать дополнительную информацию — задача весьма нетривиальная.
   
3. Практически невозможно получать информацию о структуре, которая получилась, или получается, или об каком-то участке структуры (а это бывает необходимо для реализации нетривиальных операций).
   
4. Невозможно встроиться в существующий процесс обработки объектов (т.е. там, где есть необходимая информация, мы ничего не можем делать, а где можем делать — там этой информации уже нет)
   
5. Невозможно встроиться в какое-то конкретное место структуры, чтобы реализовать там дополнительную потребовавшуюся логику.

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

КЛ>>7) Мультиметоды (не юзаю, а ты? Пр. — низкая(ИМХО))
E>Не использую и не верю, что может пригодиться
Да нет, было у меня в какой-то научной задаче, но давно и я уже не помню деталей. Помню, что без них пришлось туго, код получился совершенно неудобоваримым, хоть и работал. Но я его сваял и забыл, ибо проект не предполагал развития.
В принципе, за 10 лет промышленного программерства — 1 раз
Все по канонической присказке о парашюте.

P.S. Когда я выше употреблял слово "невозможно", я имел в виду "невозможно без полного переписывания всей подсистемы" — а в реальном работающем проекте такое переписывание проктически нереально. В результате получается как в известной карикатуре про качели, когда вырезана середина дерева, а верхушка стоит на двух свежесоструганных подпорках — очень точная аналогия: здесь в качестве вырезанной середины выступает как раз ядро инфораструктуры классов, оказавшейся абсолютно бесполезным (вернее, мешающим) для решения текущей задачи, и в результате задача решается через приставление все большего количества костылей в разных местах инфраструктуры.

P.P.S. Хотя, с другой стороны, никто не мешает объявить самым модным новый метапаттерн "костыли" — тогда все будет в полном соответствии с ныне модной методологией разработки

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

Здравствуйте, 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 люди проекты рожали, хотя тоже учебный язык вроде как был поначалу

A>Посмотри

Автор: Left2
Дата: 20.04.06

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

И? Что я сказал непонятного? Я действительно говорю об использовании глобальной переменной в качестве синглтона. "тсчетность" (я так понял это тщетность?) в чём?

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

A>>Вообще, надо иметь смелость сказать, что глобальные объекты эквивалентны синглтонам.
E>Ну я имею смелость заявить даже больше: "Синглетоны -- это и есть глобальные объекты. От синглетонов не надо ничего большего, по сравнению с глобальными объектами"

Есть такое мнение, что разница между Синглетон и глобальным объектом заключается в том, что глобальный объект создаётся сразу, а Синглетон — при первом обращении.

ЗЫ Естественно, можно и глобальный объект сделать как PIMPL с IMPL, создающимся по требованию, но это уже Синглетон , хотя в паттернах нет явных границ, так что как хотите так и называйте.

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

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

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

J>Вот здесь присоединяюсь.
J>На мой взгляд, этот паттерн — один из самых неудачных.
Неудачных паттернов не бывает. У всех у них есть свои недостатки и преимущества. Неудачным бывает место его применения. К тому же, там все просто до ужаса, в чем там можно запутаться? Ну да ладно, вам виднее.

"programmater" <34509@users.rsdn.ru> wrote in message news:1859643@news.rsdn.ru...
> Здравствуйте, Константин Л., Вы писали:
>
> КЛ>Здравствуйте, minorlogic, Вы писали:
>
> M>>Если я не ошибаюсь , то патерн визитор , полезен в иерархии где изменение базовых классов недопустимо , в вашем случае это было так ? Т.е. действительно нельзя было добавить пару виртуальных функций ?
>
> КЛ>Откуда такая информация? Каких виртуальных функций?
> КЛ>Упрощенный смысл визитора в том, что он позволяет статически выбирать тип объекта с помощью динамического механизма. Т.е. выбор типа объекта, с которым будем работать, делает сам объект, статически.
> Ой как сказал. Я бы не понял, если бы не знал о чем речь . А я вот не использую visitor. Из прынцыпа. Я до сих пор использую двойную диспетчеризацию (в контексте, как она описана здесь), потому как считаю, что полезная содержательная суть визитора — это двойная диспетчеризация. Все остальное — это навороты и от лукавого. И в основном для того, чтобы дотянуть его до "паттерна проектирования". Поправьте меня, если я не прав.

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

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

E>Мне известно о четырёх серъёзных попытках использовать этот шаблон. Все четыре провалились. То есть потом код был всё-таки переписан, без визитора и стал проще, лучше, понятнее и всё такое.

Догадываюсь почему, сам наступал на такие грабли
Дело в том что визитор довольно нетривиальный и крассивый паттерн. К тому же — с довольно редкими начальным условиями (небольшая иерархия классов, невозможность или сложность модификации классов в иерархии, необходимость частого добавления новых операций). Как правило тот кто читает книжку банды четырёх первый раз приходит в восторг от такого красивого и элегантного решения. Большинство паттернов он уже в каком-то виде применял, хоть и называл это как-то по-другому или вообще никак не называл — а этот — что-то новенькое. И тут же возникает соблазн вкрутить его куда-нибудь. Это куда-нибудь как правило ну очень отдалённо похоже на visitor. Но настоящему инженеру море по колено — и вот, получите визитора там где он ну совсем не нужен . Ну а потом другой инженер — который уже пробовал впихивать визитора куда не надо (или вообще никогда не читал банду четырёх) — с матом и песняками выкидывает визитора и впедаливает куда как более простое и эффективное решение. Ну а после этого пишет на RSDN поднимая вопрос о правомочности существования визитора как такового и паттернов вообще

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

J>>На мой взгляд, этот паттерн — один из самых неудачных.
КЛ>Неудачных паттернов не бывает. У всех у них есть свои недостатки и преимущества. Неудачным бывает место его применения. К тому же, там все просто до ужаса, в чем там можно запутаться? Ну да ладно, вам виднее.

Там все просто, пока ты остаешься на уровне 'hello world', пока не дойдет до реального кода, который выдержал с десяток запросов от бизнеса/пользователей.
А в реальном коде все превращается в монстра типа того, о котором я рассказал.
У тебя ведь у самого реального опыта с этим паттерном нет, насколько я понимаю из треда выше.
Вот когда твой код с визиторами таким образом (десяток выполненных запросов) заматереет, тогда и поговорим.

Я вполне допускаю, что сейчас тебе все нравится, но вот что останется от этого кода после того, как по нему 10 раз пройдутся программисты, решая совершенно разные задачи, которые перед ними поставили пользователи? Насколько им будет удобно ворочаться в твоей визиторской структуре?
Насколько после этих перепахиваний код останется красивым и простым, и вообще останется ли он, или очередной бедолага, у которого вдруг оказалось свободное время, просто возьмет и перепишет все заново?

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

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


L>И тут же возникает соблазн вкрутить его куда-нибудь. Это куда-нибудь как правило ну очень отдалённо похоже на visitor. Но настоящему инженеру море по колено — и вот, получите визитора там где он ну совсем не нужен .

не в глаз а в бровь

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



C>Сравните:
C>

doc->>GetPage(page_num)->GetItem(item_num)->SetSelected(false);
C>

Ну это смотря как импортировать библиотеку типов:

#import <msxml4.tlb>

//...
rootNode->appendChild(node->GetownerDocument()->createElement(L"name"));

Правда это удобно только в клиентском коде

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 поднимая вопрос о правомочности существования визитора как такового и паттернов вообще

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

Примеров что-то пока никто убедительных не привёл пока. В том числе и про визитёра

Здравствуйте, 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

Здравствуйте, Anton V. Kolotaev, Вы писали:

AVK>Typelist'ы из Loki применяются в Nebula-2 — open source графическом движке.

А зачем?
Казалось бы граф. движок не должне быть сверхсложен архитектурно.

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

E>Казалось бы граф. движок не должне быть сверхсложен архитектурно.

Интересно, на чем основано это мнение?

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

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


R>>Вобщем, что я хочу сказать. Есть вещи более простые, но с мменьшими возможностями (например, возьмёт логарифмическую линейку), а есть вещи более сложные, но с большими возможностями (например, возьмём компьютер). Конечно, человек, который 20 лет проработал с логарифмической линейкой, скажет про использование компьютера, что это сложно, что это не нужно, что это непонятно, что я так привык.
R>>Всё всегда идёт к усложнению и к большим возможностям. Это неизбежно. Но тут надо не отставать от жизни.
R>>Всегда существуют двигатели прогресса, которые исследуют новые возможности, потом облачают их более простую, понятную и пригодную для использованию форму. И после этого новые возможности становятся достоянием народа. Взять, например, современный автомобиль, штука офигеть какая сложная, зато возможностей сколько и использовать как просто. Всё. Мне пора в философию или о жизни

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

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


E>Но с исключениями немного лучше всё-таки. В том числе надёжнее.
E>Но надежнее он, кстати, не из-за исключений, а из-за scope guards, продуманной схемы владения объектами и другихарихитектурных достижений.
E>Собственно улучшают прогамму в основном они.
E>А уж когда ты их внедрил, то код с исключеними становится проще и понятнее

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

E>А что и куда надо внедрить, чтобы стал проще и понятнее код с мультиметодами, например, я не знаю

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

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


R>>boost.mpl — штука сложная. внутри. но облечённая в удобную для использования форму. и документированная хорошо. Я не вижу ничего плохого в использовании её в промышленном проекте. Я даже надеюсь на то, что когда придёт новый программист, он скажет "о, вы тут mpl используете. конечно я работал с ним. я понимаю этот код".

E>
E>Всё хорошо, но я не знаю зачем он нужен. В том смысле что не знаю примеров удачного его использования


Допустим тебе надо реализовать две функции.

//Первая
ISomePtr func(Type& value)
{
  //... что-то
  return ISomePtr(new SomeImpl1(value));
}

//Вторая
ISomePtr func(Type& value)
{
  //... что-то
  return ISomePtr(new SomeImpl2(value));
}

Причём, что бы первая вызывалась для типов int, unsigned, short, unsigned short, long, __int64. А вторая для string, wstring, const char*, const wchar_t*.

Как бы ты предложил это реализовать?