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

WH>Главное то что если библиотека .НЕТовская то никаких проблем нет.
Ха, ну и библиотека на C++ могла бы предоставить возможность удобно совместно владеть своими объектами

Конечно если что-то уже реализовано, то проблем не будет

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

E>>ИМХО свои контейнеры дешевле в поддержке...
WH>Автоматические тесты не пишем принципиально?
Пишем конечно. Но для своих контейнеров, в не для развесистого буста + непонятной системы ограниченя его использования

E>>Ну вот я и делюсь опытом таких проверок. У нас он однозначный...
WH>У меня тоже... и похоже прямо противоположный твоему...
ВОзможно секрет в альтернативе STL. Если не STL, то что? Голые сишные вектора или какая-то вменяемая библиотека контейнеров?

WH>У меня получается. Но тут нужно говорить предметно, а не вобщем.
WH>И результат избавления от всяких там статиков и синглетонов всегда оказывался положительным.
Хорошо. Вот, например, что ты думаешь о статическом на поток (или просто статическом, в случае однопоточного окружения) логе?
Или, например, о статических таблицах данных. Скажем таблице, в которой написано какие ключи есть в каких иероглифах...

E>>Но это всё непринципиально, вообще-то. Исключения тут не главное. Главное -- свойства кода.
WH>Какие такие свойства?
Некритическая зависимость от исключений и шаблонов и т. д.
Вот смотри. Если у тебя прога написана так,ч что в случае какой-то лёгкой платформы без исключений, ты можешь из любого места сохраниться, выдать предупреждение и перезапустить прогу, а на нормальной платформе возбудить исключение и обработать его на уровне запроса, то у тебя практически весь код будет разделяться этими версиями и обе будут хорошо работать.
А если у тебя весь код пропитан throw и catch, то даже без легковесной платформы понятно, что он очень зависим от исключений...

E>>Э-э-э? Как? Переписать весь код?
E>>Вот написал ты всё в стиле

template<typename TIterator> void my_foo( TIterator start, TIterator end )

и что делаем дальше?
WH>И что? Если это не понимает компилятор С++ то это уже скорее компилятор С. И тогда тебе нужно писать на С.

E>>Да и потом это всё не важно. Просто почитай доки про загрузчик или напиши сэмпл...
WH>Угу... мне это конечно же приснилось...

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

E>>Вот написал ты всё в стиле

template<typename TIterator> void my_foo( TIterator start, TIterator end )

и что делаем дальше?
WH>И что? Если это не понимает компилятор С++ то это уже скорее компилятор С. И тогда тебе нужно писать на С.

Ну считай, что это не C++, хотя там есть строгая типизация, перегрузка, какие-то шаблоны (пусть с багами и "особенностями"), операторы, и, возаможно, даже исключения.
Делать-то что?
С другой стороны я утверждаю, что даже если нет нужды переносить прогу на платформу с плохими шаблонами, то код, котрый "зависит от шаблонов некритически" обычно лучше, понятнее, проще, легче в поддержке и развитии...

E>>Да и потом это всё не важно. Просто почитай доки про загрузчик или напиши сэмпл...
WH>Угу... мне это конечно же приснилось...
Ну ты собственно чтооспариваешь?
Что в OS Linux загрузчик процесса видит все символы в SO'шке и в процессе и может их линковать друг к другу как попало? Ну проверь этот факт. Это так, увы авторам линуха

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

E>>Тем более, что любой интерфейс можно завернуть в автогенерённый переходник. Проблема в доступности symbols друг друга.

RO>so/dll не должны зависеть от языка. Представляю, как ты вызовешь из Perl функцию с замангленным именем, которая бросает исключения.

Конечно если ты зовёшь so из PERL, то с-интерфейс удобнее, чем c++
И дело даже не в мангленгом, а в том, что тебе прийдётся ловить исключения или создавать/разрушать объекты. Но эта проблема легко лечится, как раз. Вторая проблема намного рудне искоренима.

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

E>Ха, ну и библиотека на C++ могла бы предоставить возможность удобно совместно владеть своими объектами


E>Конечно если что-то уже реализовано, то проблем не будет
Оно реализовано на качественно ином уровне чем можно сделать на С++.

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

E>Пишем конечно. Но для своих контейнеров, в не для развесистого буста + непонятной системы ограниченя его использования
Прелесть boost'а и stl в том что они уже протестированны.

E>Хорошо. Вот, например, что ты думаешь о статическом на поток (или просто статическом, в случае однопоточного окружения) логе?
Однозначно в морг.

E>Или, например, о статических таблицах данных. Скажем таблице, в которой написано какие ключи есть в каких иероглифах...
Против констант заданных на этапе компиляции я ничего не имею.

E>Некритическая зависимость от исключений и шаблонов и т. д.
Все както слишком расплывчато.

E>Вот смотри. Если у тебя прога написана так,ч что в случае какой-то лёгкой платформы без исключений, ты можешь из любого места сохраниться, выдать предупреждение и перезапустить прогу, а на нормальной платформе возбудить исключение и обработать его на уровне запроса, то у тебя практически весь код будет разделяться этими версиями и обе будут хорошо работать.
Рестартовать процесс на каждый чих?!
И эти люди запрещают мне ковыряться в носу...

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

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

E>>Ха, ну и библиотека на C++ могла бы предоставить возможность удобно совместно владеть своими объектами
WH>

E>>Конечно если что-то уже реализовано, то проблем не будет
WH>Оно реализовано на качественно ином уровне чем можно сделать на С++.

Насколько я помню, люди приводили конекретную проблемную ситуацию. С вполне конкретными библиотеками. Конечно если бы всё было совсем другим, то и жить можно бы было по-другому

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

E>>Пишем конечно. Но для своих контейнеров, в не для развесистого буста + непонятной системы ограниченя его использования
WH>Прелесть boost'а и stl в том что они уже протестированны.
А процедура контроля границ использования boost и корректности его текущей развёртки?

E>>Хорошо. Вот, например, что ты думаешь о статическом на поток (или просто статическом, в случае однопоточного окружения) логе?
WH>Однозначно в морг.

Очень аргументированно.
Ответ -- не убелил

E>>Или, например, о статических таблицах данных. Скажем таблице, в которой написано какие ключи есть в каких иероглифах...
WH>Против констант заданных на этапе компиляции я ничего не имею.
А если на этапе компиляции эти данные вычислить затруднительно?

E>>Некритическая зависимость от исключений и шаблонов и т. д.
WH>Все както слишком расплывчато.
Ну я уж как мог объяснял что такое "критическая зависимость" и что такое "некритическая". Ты уж прости, но понятнее я пояснить не смогу.
В конце концов "специалиста учить -- только портить". Если тебе понятие "критическая зависимость кода от шаблонов" не доступно, ну значит не доступно. Я не знаю как ещё объяснить. Попробуй задать вопросы, что ли

WH>Рестартовать процесс на каждый чих?!
На некоторых платформах это довольно дёшево. Но поинт состоит ка краз в том, что на каждый чих не надо использовать исключения...

E>>А если у тебя весь код пропитан throw и catch, то даже без легковесной платформы понятно, что он очень зависим от исключений...
WH>А в чем проблема если это код никогда не будет запускатся на этих твоих "легковесных платформах".
Э-э-э? А зачем его тогда туда переносить? (Я уж не говорю о том, что делать, если компиллер не знает таких слов...)

> При удалении *объекта*, но не при удалении *указателя*, как ты написал.

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

> И при удалении объекта надо обходить не весь список умных указателей своего типа, а весь список умных указателей, которые ссылались на этот объект.

Да, действительно. Но тогда у нас и присваивание указателей затратным станет —

smart_ptr<A> a(new A);
smart_ptr<A> b = a;
smart_ptr<A> c(new A);
a = c;

В последнем присваивании придется тоже обходить список первого объекта.

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

>> При удалении *объекта*, но не при удалении *указателя*, как ты написал.

S>Ну при удалении умного указателя тоже ведь понадобится сказать объекту, что на него этот конкретный умного указатель больше не указывает? Иначе потом при удалении объекта будет обращение по неправильному указателю.

Объект ничего не хранит. Ему ничего говорить не надо.
При удалении умного указателя надо его удалить из списка сказателей, указывающих на этот же объект. Это O(1).

>> И при удалении объекта надо обходить не весь список умных указателей своего типа, а весь список умных указателей, которые ссылались на этот объект.

S>Да, действительно. Но тогда у нас и присваивание указателей затратным станет —
S>

S>smart_ptr<A> a(new A);
S>smart_ptr<A> b = a;
S>smart_ptr<A> c(new A);
S>a = c;
S>

S>В последнем присваивании придется тоже обходить список первого объекта.

Ничего обходить не надо.
Тут объект а удаляет себя из списка указателей, указывающих на первый объект, и добавляет себя в список указателей, указывающих на второй объект. Это очень быстро и O(1).


Дабы снять непонимание. Никто не хранит как таковой список всех указателей, указывающих на конкретный объект. Все указатели сами организованы в распределённый список. Каждый имеет next и prev на соседние указатели, указывающие на тот же объект. При удалении указателя, он просто удаляет себя из этого списка.

E>Конечно. Только то, что STL нифига не ключевая технология успеха
E>Кроме того в STL есть свои проблемы и свои косяки. Можно обсудить разные конкретные обстоятельства, но где-то тут уже был такой флейм. Лично мне в STL контейнерах не больше всего ненравятся три обстоятельства
E>1) Элементы должны иметь семантику значения
E>2) Сильно навязывается некоторый подход к использованию памяти. Пир этом сам этот подход немного неудобен
E>3) Провоцирует неоправданное использование шаблонов в коде. Воообще правоцирует существование шаблонов, которые никто иникогда не проэктировал.

А можешь пояснить пункты 2 и 3 чуть подробнее? Пункт 2 — это про отсутствие realloc, насколько я понял? А пункт 3 — не понял совсем, как-то не натыкался на такую проблему.

E>КРоме того мы отказались не только от STL, но и от MFC, от PowerPlant, и много от чего ещё
Дык извините — это специфика Огромный проект (вариант — серия проектов), большие ресурсы и серьёзные требования к производительности/памяти — вот и весь рецепт. Тут я даже не представляю стандартную библиотеку, которая впилась бы и от которой не было бы попыток отказаться . STL (boost) — это попытка баллансирования, попытка решить 90% задач по крайней мере не хуже, чем решают их 90% альтернативных библиотек. Если вы в эти 90% не попадаете — ну что ж, STL/boost действительно не для вас.

Тут недавно статейка проскакивала про ESTL — "свой" STL от Electronic Arts, заточеный и расширеный под написание игрушек для разных платформ. У тебя, похоже, тот же случай — только STL не лёг в основу фирменной библиотеки. Единственно, делать вывод о ненужности STL потому что он не нужен конкретно твоей организации — я всё же не стал бы

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

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

RO>>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

E>Это помогает под виндой.
E>Под Linux'ом загрузчик запросто может прилинковать потроха SO к потрохам хоста. И ничуть не запарится. Так что какой там интерфейс -- не суть. Тем более, что любой интерфейс можно завернуть в автогенерённый переходник. Проблема в доступности symbols друг друга.

Мы такие проблемы решали прятанием символов с помощью version script. Например, приходится делать что-то типа такого:

{
local:
    extern "C++"
    {
        std::*;
    boost::*;
    };
};

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

E>>Конечно. Только то, что STL нифига не ключевая технология успеха

E>>2) Сильно навязывается некоторый подход к использованию памяти. Пир этом сам этот подход немного неудобен
L>Пункт 2 — это про отсутствие realloc, насколько я понял?
Не только. Например на STL неудобно размещать короткие вектора прямо на стеке, скажем...

E>>3) Провоцирует неоправданное использование шаблонов в коде. Воообще правоцирует существование шаблонов, которые никто иникогда не проэктировал.
L>А пункт 3 — не понял совсем, как-то не натыкался на такую проблему.
Ну как же. Вот надо тебе написать какой-нибудь алгоритм в STL-стиле. Пишеш не функцию, а шаблон. Обычно параметризованный итератором. Всё конечно хорошо, но реальная жизнь показывает, что эту функцию/функтор никто как шаблон никогда не проектирует. Соответсвенно рожабт всяких уродов.

L>Если вы в эти 90% не попадаете — ну что ж, STL/boost действительно не для вас.
Ну я про то же. Что для совсем маленькой разработки STL пиремлем, если нет другой, более подходящей либы. Тем более, что он переносим, хотя бы в смысле стандарта STL
А вот если проект большой или много, дешевле иметь специализированную конструёвину

L>Единственно, делать вывод о ненужности STL потому что он не нужен конкретно твоей организации — я всё же не стал бы
Да нет. Я о ненужности STL вывод делаю. А совсем другой.
1) И без STL жизнь может быть хорошей. Внедрять STL из идеологических соображений, ИМХО, неправильно. Нужнопонимать акую выгоду это принесёт. Тем более, что в случае хорошей жизни может принести и убыток.
2) Выбирная STL надо понимать что за проблемы и особенности производства разработки он за собой "притянет".

Короче всё как всегда. Выбирая инструмент, нужно понимать почему тебе нужен именно такой инструмент, а не какой-то другой

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

AA>Мы такие проблемы решали прятанием символов с помощью version script. Например, приходится делать что-то типа такого:

Это помогает только если у тебя не коллекция SO-шек, с С++ интерфейсом между собой и каким-то интерфейсом наружу.

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

E>1) Кто-то должен поддерживать актуальность требований на использование А, Б и В, и следить за их соблюдением
это необходимо в случае любой библиотеки, в том числе самописной.

E>2) Буст сам по себе время от времени меняется. Надо как-то понимать нужно ли и можно ли включать эти изменения в твой билд. При этом решение лучше бы принимать на уровне всей конторы, как минимум, а то момтом случится конфликт версий
Буст меняется раз в два года (1.33.1 был в 2005 году). Раз в два года можно и обновиться всей конторой, это ж не каждую неделю..
Ну и "как-то понимать", естественно, необходимо. Тестировать тщательно и все такое прочее. Вот скажем, вышел 1.34.1 — ты думаешь, мы уже радостно на него перешли? Нет еще, хоть и собираемся, когда будет достаточно времени, чтобы протестировать его (это месяца через два, наверное, не раньше). Взяли из него только некритичные вещи с сильными изменениями, типа буст.тест — они все равно используются только в тестовых прогах. А у вас в конторе не так? Новая версия самописной или третьей библиотеки (не буста, свят,свят,свят!) просто инсталлируется и используется как есть?

E>3) Иногда в фреймворке что-то хочется развить или баг пофиксить. В случае, если это буст, то от тебя приоритет этой работы не зависит, да и даже когда команда буста это сделает, результатами её работы ещё надо суметь воспользоваться, не сломав переходом на новую версию буста всё остальное
Во-первых, никто не мешает накатывать патчи, если они необходимы. Вроде народ исправно накатывал патчи на ту же MFC и не жаловался.
Во-вторых, все доступно в исходниках — меняй, если что-то не нравится.
Причем это не GPL, так что ты не обязан сабмитить свои изменения куда-либо.
Например, мы спокойно поменяли пару вещей в буст.тест, потому что нас оно не вполне устраивало, и не испытываем по этому поводу никаких угрызений совести.

E>Ну если ты рожаешь библиотеку под Linux, то там все symbols видны во всём приложении. Так что если у твоей библиотеки и хста разные версии буста или STL, то всё вместе работать будет только в среднем
E>Конечно если ты поставляешь изделие в исходниках, то клиент сам может скомпилировать с нужной версией буста (если сможет конечно, и отладить тоже), но если ты исходники не предоставляешь, то должне использовать такой же буст, какой у клиента...
если заказчик пользуется бустом, то он обычно и говорит, какой именно версией он пользуется, и надо разрабатывать на этой версии.
если не пользуется — значит, надо ему отдавать библиотеки той версии, которую ты используешь.
Не вижу проблемы.

J>>Да им вообще ничего не нужно. Напишут они все на голом С, на указателях на void, и если релиз прошел — все, экономически эффективно. А то, что потом поддержка превращается в кошмар — это уже неэффективность поддерживающей команды, а у изначальной все хорошо, релиз же прошел.
E>Ну да, не только процесса разработки а всегопроцесса использования и разработки кода. Обычно конторы быват либо такие, которые пишут одноразовые решения, и там действительно пофиг на стоимость поддержки. Главное быстро и дёшево разработать (иначе просто не будет спроса на такую услугу, так как проще "девочку посадить")
E>А бывает так, что пишут долговременные решения. С версиями, с поддержкой, со всеми пирогами. И там вполне могут быть разные бизнес-модели. Типа ты можешь решить, что поддержка за время разработки след. версии должна быть не дороже 30% разработки. Ну и измеряй себе экономическую. эффективность процесса в целом, соответсвие его бизнес-моделям и т. д.
Естественно. Набрать обезьянок и заставить их работать круглосуточно "за строчку в резюме".
Мне дед рассказывал историю про одного председателя колхоза, который показал рекордный урожай и получил Сталинскую премию.
А потом выяснилось, что он просто засеял заодно и поля, которые должны были быть под паром, а центнеры с гектара рассчитал только с разрешенных площадей.
Я к тому, что снаружи (по официальным отчетам) все может выглядеть хорошо, типа дешевые программеры, работают 8 часов в день, а на самом деле они и на выходных сидят.
И получается софт, который чудо как хорош по всем показателям, кроме затраханности персонала, о которой никто, кроме самого этого персонала, не знает. Конкретному примеру в следующем году 15 лет стукнет. С версиями, с поддержкой, со всеми пирогами.

J>>"в реальности бывает" не означает "везде", а означает "бывает". Я описанную ситуацию наблюдал многократно, и не только в фирмах, где я работал.
E>Да, так тоде бывает. АФАИК, обычно так бывает вне связи с использованием STL. Мало того, если корреляция есть, то я бы предположил, что она обратная. То есть проекты написанные с буст и STL скорее могут оказаться "бесхозными"
У меня другой опыт

E>Ну я уже рассказывал схему такого сервиса. Когда ты регишь всё критичное объекте запроса, а промежуточные аллокации все делаешь на убиваемомо аллокаторе. И в случае ошибки освобождаешь всё критичное, а всё некритичное просто грохаешь всем аллокатором. Ну и вместо исключений используешь глобальный goto или вообще перезапуск приложения (на платформах без исключений это может бытьочень дешёвой процедурой)
На юниксах это делается гораздо проще: открывается сегмент общей памяти и запускается процесс, который возьмет из него данные, сделает всю работу в своей личной куче, и результат сложит обратно в общую память, после чего помрет и свою кучу с собой прихватит.
И никакой возни с аллокаторами.

E>>>>>>>

---

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

E>Ну я вот знаю разных многопоточных разработчиков. Я так тебе скажу, что основные проблемы у них не от того, что их как-то там ОС кидает, а от того, что они всё делают как-то неправильно. Скажем не верят, что процессор может переупорядочивать инструкции. Или не понимают как доказать невозможность дедлока в своей программе...
Ну так о чем и речь. Когда язык начнет гарантировать, что данный код, помеченный данным атрибутом, защищен от любых оптимизаций (в том числе и встроенных в процессор) — тогда ы можешь гарантировать, что твой код абсолютно корректен. И для этого нужна именно поддержка со стороны языка.
Ну должны быть в язке атомарные типы, ничего ты без них переносимо не сделаешь, котому что в винде это будет какой-нть InterlocetIncrement, а в gcc — atomic_t.

E>Так что стнадартизация, как способ заставить всех наконец прочитать пару книжек -- это, ИМХО, оверкил
Почему? Скажем, если бы стандартизировали, что выражения, в которых встречаются volatile-переменные, должны исполняться в точности как написано — было бы гораздо проще.
Просто посмотри сюда: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2336.html
Будешь точно знать ,что именно обсуждается.
Конкретно: разделы "Active topics in Concurrency sub-group" и "Active topics in both Concurrency and Library sub-groups" (ну и "Background papers for reference" до кучи).
Можешь и сразу сюда заглянуть, чтобы понять, что имено должно быть в языке, если не хочется на каждый чих ставить мьютекс:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2300.html

E>Кстати, опять же, мне кажется, что больше всего пользу миру принесло бы появления какой-то стандартной "облегчённой" многозадачности. Чтобы она использовалась либо на уровне цикла, либо на уровне запроса. И для синхронизации использовались бы какие-нибудь асинхронные методы. Что-то типа окошечных сообщений/яблочных событий. Но это моё скромное ИМХО
ну так есть фьючерсы, есть work stealing, много идей вообще бродит на эту тему.

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

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

E>А процедура контроля границ использования boost и
А нафига?
Ну если очень хочется можно сказать что можно из буста использовать только такието библиотеки.

E>корректности его текущей развёртки?
Буст развертывается скриптами на раз.

E>Очень аргументированно.
E>Ответ -- не убелил
См в архитектуре флеймы про синглетоны.

WH>>Против констант заданных на этапе компиляции я ничего не имею.
E>А если на этапе компиляции эти данные вычислить затруднительно?
Например?

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

E>Э-э-э? А зачем его тогда туда переносить?
И я о томже.

E>(Я уж не говорю о том, что делать, если компиллер не знает таких слов...)
У меня VC++8.0 и g++3.3 они понимают весьма много слов.

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

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

AA>>Мы такие проблемы решали прятанием символов с помощью version script. Например, приходится делать что-то типа такого:

E>Это помогает только если у тебя не коллекция SO-шек, с С++ интерфейсом между собой и каким-то интерфейсом наружу.

Не понял. Это помогает от экспорта того, что не надо экспортировать — в данном случае от экспорта STL символов из заголовочных файлов, используемых в реализации библиотеки. В gcc 4.x это можно решить по-другому, но не суть. Ты же описываешь что-то другое, судя по всему?

Или имеется в виду, что есть две группы библиотек, tightly coupled С++ интерфейсом, которые пользуют в интерфейсах boost (но только внутри между собой) и так случилось, что они используют boost разных версий? В этом случае, да, приплыли. Boost не приспособлен для этого. И не только Boost. Впрочем, можно отверсионировать namespace — так мы тоже делаем

E>>>Конечно. Только то, что STL нифига не ключевая технология успеха

E>>>2) Сильно навязывается некоторый подход к использованию памяти. Пир этом сам этот подход немного неудобен
L>>Пункт 2 — это про отсутствие realloc, насколько я понял?
E>Не только. Например на STL неудобно размещать короткие вектора прямо на стеке, скажем...
Согласен. Но это скорее "недоделки" чем принципально неразрешимые проблемы.

E>>>3) Провоцирует неоправданное использование шаблонов в коде. Воообще правоцирует существование шаблонов, которые никто иникогда не проэктировал.
L>>А пункт 3 — не понял совсем, как-то не натыкался на такую проблему.
E>Ну как же. Вот надо тебе написать какой-нибудь алгоритм в STL-стиле. Пишеш не функцию, а шаблон. Обычно параметризованный итератором. Всё конечно хорошо, но реальная жизнь показывает, что эту функцию/функтор никто как шаблон никогда не проектирует. Соответсвенно рожабт всяких уродов.
Э... А что — часто приходится клепать аналоги std::sort или там std::partial_sort? Ну и в любом случае — функтор который в алгоритм передаётся абсолютно никак не обязан быть шаблоном. Или я недопонял чего-то?

L>>Если вы в эти 90% не попадаете — ну что ж, STL/boost действительно не для вас.
E>Ну я про то же. Что для совсем маленькой разработки STL пиремлем, если нет другой, более подходящей либы. Тем более, что он переносим, хотя бы в смысле стандарта STL
E>А вот если проект большой или много, дешевле иметь специализированную конструёвину
Тут всё упирается в количественное измерение "большой" или "много". Сдаётся мне, что 90% проектов (или скажем так — проекты, в которых работают 90% программистов) в понятия "большой" или "много" не попадают . Особенно у нас, где процветает аутсорсинг который как правило либо небольшие проекты, либо поддержка legacy систем.

L>>Единственно, делать вывод о ненужности STL потому что он не нужен конкретно твоей организации — я всё же не стал бы
E>Да нет. Я о ненужности STL вывод делаю. А совсем другой.
E>1) И без STL жизнь может быть хорошей. Внедрять STL из идеологических соображений, ИМХО, неправильно. Нужнопонимать акую выгоду это принесёт. Тем более, что в случае хорошей жизни может принести и убыток.
Э... Тут позволю себе не согласиться STL внедрять не надо Он в подавляющем большинстве случаев — уже есть И это — огромное преимущество перед библиотеками класса "сам пан склэпав" которые ещё предварительно надо склепать

E>2) Выбирная STL надо понимать что за проблемы и особенности производства разработки он за собой "притянет".
Согласен, но хочу подчеркнуть одну особенность — в случае STL эти проблемы и особенности можно в течение 10 минут найти гуглом. В случае third-party или самописной библиотеки — эти проблемы это поле с высокой травой и разбросанными граблями

E>Короче всё как всегда. Выбирая инструмент, нужно понимать почему тебе нужен именно такой инструмент, а не какой-то другой
Согласен целиком и полностью

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

R>Ничего обходить не надо.
R>Тут объект а удаляет себя из списка указателей, указывающих на первый объект, и добавляет себя в список указателей, указывающих на второй объект. Это очень быстро и O(1).


R>Дабы снять непонимание. Никто не хранит как таковой список всех указателей, указывающих на конкретный объект. Все указатели сами организованы в распределённый список. Каждый имеет next и prev на соседние указатели, указывающие на тот же объект. При удалении указателя, он просто удаляет себя из этого списка.

Все, на сегодня тупить закончил. Совершенно упустил из вида, что для удаления указателя нам его искать не надо. И может быть даже удастся обойтись без мьютекса, одними CAS'ами.

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

E>>Не только. Например на STL неудобно размещать короткие вектора прямо на стеке, скажем...
L>Согласен. Но это скорее "недоделки" чем принципально неразрешимые проблемы.
Ну я бы сказал, что в STL на вопрос управления использованием памятью просто забили. И при этом привинтить это туда прямо не совсем удобно. ИМХО, если есть библиотека контейнеров, где про этоу уже подумали, то это сильный плюс

L>Э... А что — часто приходится клепать аналоги std::sort или там std::partial_sort? Ну и в любом случае — функтор который в алгоритм передаётся абсолютно никак не обязан быть шаблоном. Или я недопонял чего-то?

Ну я тоже считаю, что STL-way, то есть такой способ программирования, когда можно в програме взять и заменить std::vector на std::list "если надо" -- не нужная на практике степень унификации. Но встречавшиеся мне любители связки STL + boost это дело постоянно рожают.
В конце концов STL -- это же не только набор шаблонов, но и набор соглашений о том, как нужно программировать контейнеры и алгоритмы, чтобы они были все совместимы между собой.

L>Тут всё упирается в количественное измерение "большой" или "много". Сдаётся мне, что 90% проектов (или скажем так — проекты, в которых работают 90% программистов) в понятия "большой" или "много" не попадают . Особенно у нас, где процветает аутсорсинг который как правило либо небольшие проекты, либо поддержка legacy систем.

Ну при аутсорсинге обычно всё определено требованиями заказчика Так что нет нужды обсуждать "использовать STL или не стоит"

E>>1) И без STL жизнь может быть хорошей. Внедрять STL из идеологических соображений, ИМХО, неправильно. Нужнопонимать акую выгоду это принесёт. Тем более, что в случае хорошей жизни может принести и убыток.
L>Э... Тут позволю себе не согласиться STL внедрять не надо Он в подавляющем большинстве случаев — уже есть И это — огромное преимущество перед библиотеками класса "сам пан склэпав" которые ещё предварительно надо склепать
Ну для маленькой конторы клепать не стоит. Может быть стоит развивать какую-то версию STL, только все реализации очень сложные
Но я бы на всяк. случай ещё посмотрел в сторону конкурентов. MFC там, PowerPlant и т. п.

E>>2) Выбирная STL надо понимать что за проблемы и особенности производства разработки он за собой "притянет".
L>Согласен, но хочу подчеркнуть одну особенность — в случае STL эти проблемы и особенности можно в течение 10 минут найти гуглом. В случае third-party или самописной библиотеки — эти проблемы это поле с высокой травой и разбросанными граблями
Это всё от квалификации разработчиков очень зависит.