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

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

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

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

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


Прекрасно!
Расскажи как тебе помогают в твоих многочисленных бедах мультиметоды и for_each

Главная проблема с шаблонами, ИМХО, такая, что часто при редактировании нетривильного шаблона очень трудно предсказать все последствия.
Так что кроме идеальной внимательности нужна ещё и идеальная проницательность, доходящая до уровня провидца

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

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

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

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

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

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


E>Прекрасно!
E>Расскажи как тебе помогают в твоих многочисленных бедах мультиметоды и for_each

E>Главная проблема с шаблонами, ИМХО, такая, что часто при редактировании нетривильного шаблона очень трудно предсказать все последствия.
E>Так что кроме идеальной внимательности нужна ещё и идеальная проницательность, доходящая до уровня провидца

Товарисчъ, вы когда-нибудь успокоитесь
Нука их, эти шаблоны

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

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

Используем SOA в промышленном проекте. Кроме этого, активно используем ScopeGuard.

E>Мне не нравится парадигма "сделать так сложно, как только можно".
E>Мне нравится парадигма "сделать так просто, как только можно".

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

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

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

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

1) Кто-нибудь захочет создать еще один объект CMySingletonObject, и у него это получится.
2) Проблемы инициализации и деинициализации здесь не разрешимы. (Мне долго не давал покоя один вопрос, почему Adobe Photoshop так долго стартует. Так ведь у них, наверное, всё инициализируется такими "синглтонами".)
3) Это просто глобальный объект со всеми его прелестями.

Вообще, надо иметь смелость сказать, что глобальные объекты эквивалентны синглтонам.

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

E>4) Ну и главное. В целом очень редко в программировании попадаются такие сложные задачи, что нужно то, что описано у Александреску скажем.

здесь

A>1) Кто-нибудь захочет создать еще один объект CMySingletonObject, и у него это получится.
Ну, эта-то проблема разрешима в пол-пинка Никто не мешает сделать конструкторы-деструкторы закрытыми. К основной идее это отношения не имеет.
A>2) Проблемы инициализации и деинициализации здесь не разрешимы. (Мне долго не давал покоя один вопрос, почему Adobe Photoshop так долго стартует. Так ведь у них, наверное, всё инициализируется такими "синглтонами".)
Я так понимаю, ты имеешь в виду проблемы зависимостей между синглтонами? Тут сугубо моя сугубо личная ИМХА в том что эти зависимости надо всячески искоренять. Если два синглтона зависят от инициализации друг друга — пусть они не будут синглтонами, а просто будут агрегированы внутри одного синлтона.
A>3) Это просто глобальный объект со всеми его прелестями.
Вот тут не понял В чём прелести-то? В видимости для линкера? Тоже элементарно устраняется — функция CMySingletonObject::Instace засовывается в cpp, в том же cpp пишется:

namespace
{
    static MySingletonObject g_instance;
}

И всё, об обьекте никто никогда ничего не узнает.

Ну и про photoshop — я так понял ты имеешь в виду что этот глобальный обьект может иметь "тяжёлый" конструктор? Так тоже вроде бы не проблема — если уж действительно конструктор тяжёлый — то никто не мешает сделать инициализацию по требованию.
A>Вообще, надо иметь смелость сказать, что глобальные объекты эквивалентны синглтонам.
Беру на себя смелость Я тоже одно время очень любил писать по каждому поводу отдельный синглтон — а потом понял что в 90% случаев геморрой не стоит свеч.

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

A>>1) Кто-нибудь захочет создать еще один объект CMySingletonObject, и у него это получится.
L>Ну, эта-то проблема разрешима в пол-пинка Никто не мешает сделать конструкторы-деструкторы закрытыми. К основной идее это отношения не имеет.

Создай глобальный объект после этого. Остальные твои аргументы в той же колее. Зачем начинать с глобального объекта, если ты потом начинаешь приделывать к нему возможности синглтона? Ты таким образом признаёшь, что глобальный объект, как синглтон никуда не годится.

A>Создай глобальный объект после этого.
Ну ладно, ладно — делаем ему друга и инстанцируем его через друга. Друг тоже в .cpp и никому не виден.

A> Остальные твои аргументы в той же колее. Зачем начинать с глобального объекта, если ты потом начинаешь приделывать к нему возможности синглтона? Ты таким образом признаёшь, что глобальный объект, как синглтон никуда не годится.
Затем чтобы не иметь проблем с синхронизацией. Не нужны примитивы синхронизации для создания обьекта.

A>> Остальные твои аргументы в той же колее. Зачем начинать с глобального объекта, если ты потом начинаешь приделывать к нему возможности синглтона? Ты таким образом признаёшь, что глобальный объект, как синглтон никуда не годится.
L>Затем чтобы не иметь проблем с синхронизацией. Не нужны примитивы синхронизации для создания обьекта.

И ещё одна (как по мне так главная) причина — дабы не тащить к себе библиотеку в которой синглтоны реализованы (т.е. не добавлять зависимостей в проект) и не реализовывать её самому.

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

A>>> Остальные твои аргументы в той же колее. Зачем начинать с глобального объекта, если ты потом начинаешь приделывать к нему возможности синглтона? Ты таким образом признаёшь, что глобальный объект, как синглтон никуда не годится.
L>>Затем чтобы не иметь проблем с синхронизацией. Не нужны примитивы синхронизации для создания обьекта.

L>И ещё одна (как по мне так главная) причина — дабы не тащить к себе библиотеку в которой синглтоны реализованы (т.е. не добавлять зависимостей в проект) и не реализовывать её самому.

Твоё отношение к сторонним библиотекам крайне отрицательно, тогда как решение использовать ту или иную библиотеку — это просто компромис. В нём есть и за и против. Ты видешь только одно против.

A>Твоё отношение к сторонним библиотекам крайне отрицательно, тогда как решение использовать ту или иную библиотеку — это просто компромис. В нём есть и за и против. Ты видешь только одно против.

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

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

A>>Твоё отношение к сторонним библиотекам крайне отрицательно, тогда как решение использовать ту или иную библиотеку — это просто компромис. В нём есть и за и против. Ты видешь только одно против.

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

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

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

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

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

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

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

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

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

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

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

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

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, где используются
кое-какие аналогичные решения, я использую по мере надобности (там есть много полезных вещей и без "наворотов").

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

A>1) Кто-нибудь захочет создать еще один объект CMySingletonObject, и у него это получится.
Имхо, если кто-то захочет всё сломать, он это сделает. Я не встречался с такой проблемой, что кто-то создавал бездумно вторую копию объекта, уникального по своему смыслу. Всё-так программисты они вменяемые обычно, и нацелены на результат
ИМХО все попытки сделать так, чтобы нельзя было сдлеать вторую копию синглетона -- борьба с несуществующими проблемами.
Единственный контекст, когда я такую проблему встречал -- это приложение состоящее из несколькоих DLL, но вот тогда как раз все шаблонные решения начинают пробуксовывать

A>2) Проблемы инициализации и деинициализации здесь не разрешимы. (Мне долго не давал покоя один вопрос, почему Adobe Photoshop так долго стартует. Так ведь у них, наверное, всё инициализируется такими "синглтонами".)
ИМХО проблемы инициализации и деинициализации неразрешимы в осноывном в сознании авторов синглетонов
На мой взгляд лучше всего, когда НЕТ ЗАВИСИМОСТИ между статическими объектами ПО ПОРЯДКУ ИНИЦИАЛИЗАЦИИ.
Если этого почему-то совсем совсем никак не удаётся добиться, то можно поступить так.
Взять продумать в каком же порядке это всё должно инициализироваться, чтобы было счастье.
И в каком-то одном месте, ну типа в InitInstance или ещё где вызвать функции инициализации зависящих от порядка инициализации в нужном тебе порядке. При этом, когда следующий программист (или ты сам через полгода) захочет туда добавить вызов ещё одной инициализилки (или убрать) он сразу всё узнает и поправит. А не будет с полным охренением лазить по всем местам, где есть синглетоны и восстанавливать кто от кого как и зачем зависит.
Что касается фотошопа, кстати, то тоже всё интересно. Фотошоп грузит много всего. Я так понимаю, что грузить всё равно надо. Так что время идёт на доброе дело. Но вот то, что он сначала запускается, рисует сплаш, то сё, а потом начинает грузить и показывать что он при этом делает наводит мнея на мысли, что он грузит это всё опяять же в функции инициализации. Так как в случае с синглетонами, получилось бы не так.
Фотошоп бы висел три минуты после запуска, а потом бы казал сплэшскрин


A>3) Это просто глобальный объект со всеми его прелестями.
А что за проблемы в глобальных объектах, отличные от проблем синглетонов?

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

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

A>>Вообще, надо иметь смелость сказать, что глобальные объекты эквивалентны синглтонам.
E>Ну я имею смелость заявить даже больше: "Синглетоны -- это и есть глобальные объекты. От синглетонов не надо ничего большего, по сравнению с глобальными объектами"
Согласен. Вообще-то первоначально (когда компы были большими а программисты умными ) слово "синглтон" имело немного другой смысл. А именно "приложение, которое не позволяет запускать вторую (и последующие) копии самого себя". Т.е. если юзер запускал вордовый документ при уже запущенном ворде, то ворд не запускался заново, а уже существующий ворд открывал в новом окне документ, который пытался открыть юзер (как в ворд95 и ворд97). Но современные "орхитекторы" это значение слова синглтон благополучно забыли (ибо сложно в реализации, тут думать надо, понимаете ли), а додумались до класса с приватными конструкторами и запрещенными операциями копирования, единственным статическим объектом [возможно (если разработчику было не в лом) ] с отложенной инициализацией и статической функцией

static MyCoolSingleton* MyCoolSingleton::ГетИнстансе()
{
  if(MySuperPrivateInstance==0) {InitMySuperPrivateInstance();}
  return MySuperPrivateInstance;
}

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

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

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

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

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