> S>Понятно, что и без shared_ptr всё получится. Просто придется повторять часть его функциональности. Зачем, если оно уже есть готовое и отлаженное?
>
> Возможно без shared_ptr будет даже проще.

Без shared_ptr получилось следующее: "А на практике это выливается с неделю-другую выкуривания бамбука, реализации и тестирования"

> Но это не важно. Главное, что в приведённом случае это всё не помогает

С чего ты взял? От ACE_Event_Handler один черт наследоваться надо, чего б туда shared_ptr не впихнуть?

Erop пишет:
>
> 2) Профи или не профи пишут внутренние библиотеки зависит от персонала.
> Конечно если у вас в комании работают чуваки, которые вовсе и не профи а
> ламеры ламерами и ничего кроме, как использовать буст не умеют...

> 3) Перед актом велосипелостроительства, в буст можно заглянуть и
> подумать зачем им всё это. И не только в буст...

О это еще что, а вот когда и буст не умеют и stl не умеют и С++ — это С
со структурами с методами (тьфу, классами). И такое бывает, видал и не раз.
Вот тогда чаще всего велосипеды и строят.

З.Ы. Но это так оффтоп было.

Erop wrote:

> .>Дык ты сам их захотел. Вот они и появились. Или я не понял, что ты
> хочешь от этого кода. Может тебе нужне weak_ptr?
>
> Ну а теперь читаем исходное сообщение
> <http://rsdn.ru/forum/message/2631025.1.aspx&gt;

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

Я так и не понял что он не позволяет. Всё он позволяет, особенно в купе с weak_ptr. А "неэффективности" тоже ты
насочинял. Скажи чего там лишнего?

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

E>Я знаю как пользоваться бустовскими умными указателями.
E>Я просто скромно указывал, что за shared_ptr неизбежно приползёт weak_ptr...

Естественно, приползет, хотя бы потому, что он вцементирован в сам shared_ptr — есть соответствующий конструктор:
template<class Y> explicit shared_ptr(weak_ptr<Y> const & r);

Я никак не пойму, в чем "пойнт" этих выступлений. Если о том, что одна библиотека тянет за собой другую, так они оба — части одной библиотеки smart_ptr: http://boost.org/libs/smart_ptr/smart_ptr.htm

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

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

NBN>>Ерунда. Про вектор, список и shared_ptr нормальному программисту известно всё. Начиная от стратегий выделения памяти и заканчивая возможностями оптимизации. Про самопальные контейнеры это не известно и там точно есть какие-то подводные камни.

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

E>Во всяком случае, по опуту, у нас на овыладение контейнерами и умными указателями много не уходит сил. Час может. Хелп прочитать, пример написать, ну даже и не знаю что ещё дальше сделать...
Ну смотря, что понимать под "владением". Добавить/удалить элемент? Или понимать как будет выделяться память, понимать идеологию библиотеки, представлять оптимальные решения типовых задач?

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

E>Во всяком случае статей про буст там и шаблоны
E>У нас производство наукоёмкое, так что академические статьи нужны, но по предметной области, а не по тому, как написать шаредптр лучше всего

<offtop>
Вспоминаю ужос академических исходников... Брррр...
</offtop>

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

J>>не видел ты настоящего самопального контейнера
E>Ну бывают и неудачные реализации спецификации "самопальный контейнер"

Хм... Как правило бывают...
Конкретно я видел много самопала, но хороший был только мой. И то не весь

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

S>Понятно, что и без shared_ptr всё получится. Просто придется повторять часть его функциональности. Зачем, если оно уже есть готовое и отлаженное?

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

Именно поэтому, кстати, крайне редкий сборщик мусора реализован на подсчете ссылок. Пайтон пока, кажется, еще сопротивляется, но и они что-то сделают с этим, в конце концов, я думаю.

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

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

КЛ>>Какой? Мне серьезно интересно.
E>Ну я не хочу/могу разглашать место работы.
E>Особенно на форуме.
E>Одна из офисных программ, или другая, или ещё одна
E>Ещё могу такую подсказку сказать, когда искали для российских школ комплект общеупотребительных открытых программ, как альтернативу проеприетарных прог, то аналога одной из наших программ не нашли...

Название компании из 5-ти букв?

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

J>>Во-первых, нет проблем использовать некоторые библиотеки буста с вц6.0 — они вполне на нем работают.
J>>И я использовал буст в программах для смартфонов, опять же без каких-либо проблем с производительностью.

E>Речь не о проблемах производительности. А о том, что только некоторые библиотеки из boost-а будут работать с тем же vc.6.0. Но ведь тогда в чем смысл boost-а?

если я правильно понял, то все жалобы выше сводятся лишь к тому, что нужно пользоватсья bcp, чтобы выдрать кусочек библиотеки? И все?
Так я тебе скажу, что надо делать Не надо пользоваться bcp вообще. Устанавливаешь буст целиком, благо практически все библиотеки в нем header-only. И юзаешь только то, что тебе необходимо или только то, что поддерживается твоим компилятором (скажем, только shared_ptr). А другое просто не юзаешь. Очень просто

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

J>>Во-вторых, для меня есть большая разница между административным запретом типа "В нашей конторе буст, STL и прочие шаблоны запрещены. Навсегда. Я сказал" и техническим типа "На платформах, для которых разрабатывается конкретный продукт, из 5 опробованных библиотек лучшей по таким-то критериям показала себя библиотека №3, так что используем ее".

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

E>А о том, что как-то априори сейчас считается, что boost -- это наше все. Что он самый лучший по определению. А ведь не факт. Особенно в коллективах, которые начинали работать лет 10-7-5 назад. Тогда ведь принимались решения совсем в других условиях. И много отлаженного кода с тех пор было написано. Просто так от него отказываться сейчас тоже не дело.

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

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

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

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

E>Неоднократно. Только ведь заказчик -- он же всегда прав. Его не пугает даже то, что MS уже давно прекратила поддержку VC.6.0 (помнится, сие знаменательное событие произошло пару лет назад).

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

E>>>Что до всяких shared_ptr, то в многопоточной программе еще не факт, хорошая это штука или нет.
J>>Это тема отдельного большого разговора, и boost::shared_ptr будет занимать в нем крайне незначитальную часть

E>Вот-вот. А горячие головы при этом будут говорить: стандартная проблема, стандартное решение /прошу никого не обижаться, все совпадения с реальными участниками дискуссии являются совершенно случайными :beer:/

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

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

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

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

E>>Потом производитель девайса по каким-то своим юридическим причинам был вынужден срочно сменить платформу. УПС. Ребятам пришлось на ходу переноситься ещё раз. А вот на новой платформе шаблонов в С++ просто не было

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

RO>Вот если бы тот код скомпилировали с помощью EDG front end, который переводит C++ в C, то что, этот код на C не скомпилировался бы?

RO>Кстати, «шаблонов в С++ просто не было» — с логической точки зрения это утверждение всегда ложно

Компиляторы-то не дороге валяются. Erop может неверно выразился, но суть-то ясна.

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

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

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

B>>>Ну вы же наверяка не ограничились умными указателями
B>>>Предположу, что у вас и строки, контейнеры и стандартные алгритмы тоже самобытные
B>>>Так, по мелочам, только на ознакомление точно удет ненулевое время.

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

B>Я не адекватен
B>У меня уйдет точно больше времени.
B>Насколько больше — это сильно зависит от самобытности контейнеров.
B>Предела самобытности не существует

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

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

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

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

Итак, кто какой самый "самобытный" массив видел? Такой, чито фиг въедешь?

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


E>>Во всяком случае, по опуту, у нас на овыладение контейнерами и умными указателями много не уходит сил. Час может. Хелп прочитать, пример написать, ну даже и не знаю что ещё дальше сделать...
NBN>Ну смотря, что понимать под "владением". Добавить/удалить элемент? Или понимать как будет выделяться память, понимать идеологию библиотеки, представлять оптимальные решения типовых задач?

Ну вот примерно на это и надо час где-то. Может ещё час на иделологию библиотки в целом (там есть некоторая фишка по поводу тонкостей работы с памятью)

Вот в целом-то и всё...
Во всяком случае всё с контейнерами.

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

NBN>Конкретно я видел много самопала, но хороший был только мой. И то не весь
Ну весь не весь, но бывают "самопальные" контейнеры, которые, по крайней мере, не хуже STL уж точно...

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

J>Так я тебе скажу, что надо делать Не надо пользоваться bcp вообще. Устанавливаешь буст целиком, благо практически все библиотеки в нем header-only. И юзаешь только то, что тебе необходимо или только то, что поддерживается твоим компилятором (скажем, только shared_ptr). А другое просто не юзаешь. Очень просто
Увы, есть пара подводных камней.
1) Довольно трудно ограничить использование разработчиками только того "что надо" из буста
2) Когда гром таки грянет не всегда просто понять, а что же таки наиспользовали господа разработчики и что же из буста реально работает, и что использовани переносимо...
В этом смысле своя библиотека радикально лучше управляема и поддерживаема.


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

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

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

Ну часто так бывает, что "совсем нового кода" не бывает. А если он таки бывает, то никто не гарантирует, что в конце концов он не пересечётя со старым. Другое дело, что старый код лучше всё-таки поддерживать в хорошем состоянии и не забывать рефакторить при нужде.
Идея в том, что если в конторе нормально поставлено дело и она старая, то тами без буста и без STL всё более или менее нормально. А что ненормально -- выпрямляют, безотносительно к внедрению STL'я.

J>Далее, эти все соображения относятся не только к использованию или неиспользованию буста, а к более чувствительным вещам, например: работают ли в принципе на данной платформе исключения, есть ли многопоточность и если есть, то в каком виде, какие возможности кучи/стека и т.д. Вполне может оказаться, что придется переписывать (и перепроектировать) программу с нуля, несмотря на то, что он в смысле буста девственно чиста.
У меня есть заметный опыт в переносе кода на разные платформы. А у нашей конторы такого опыта вообще вагоны. В том числе на экзотические и довольно убогие. Среди убогих были и такие, где не было возможности иметь конструкторы статических объектов и такие, гед не было исключений, и такие, где шаблоны были не супер. ИМХО "крутые" шаблоны тяжелее всего переносить в таком раскладе. Потому, что они весь код пронизывают и часто трудно понять что там должно произойти, если их оттуда отковырять.
Второй источник гемора -- это конечно исключения. Но при некотором подходе к использованию исключений можно получить все адвантез, и при этом не сильно попасть, в случае, если таки надо от исключений избавится.

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

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

---

J>Почему горячие? Ведь действительно стандартная библиотека и т.д. — посмотри драфт стандарта.
J>Другое дело, что (вот ты меня все-таки хочешь вытянуть на этот долгий разговор, да?) с многопоточностью в С++ вообще большие проблемы, встроенные, в дизайне языка. И свет пока что виден только в C++0x — собственно, это главный приоритет следующего стандарта: нормальная поддержка многопоточности со стороны языка (атомарные типы, барьеры и т.д.)

Вот многопоточность -- это да. Только мне кажется, что C++ всё ранво для многопоточности будет не супер. Тут нас ещё ждут какие-то революции и свершения
Мне так кажется, что решения должны быть либо ориентированы на какую-то мегамногопроцессорную платформу, но тогда надо совсем другой язык писать, наверное функциональный какой-то, либо должна быть поддержка распараллеливания на каком-то очень высоком уровне. Типа на уровне запроса. Но тогда это скорее не к языку, а к ОС и библиотекам...

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

AA>Название компании из 5-ти букв?
Ну я и так много сказал. Но на одном из языков одно из слов действительно из пяти букв

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

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

А как shared_ptr помогает от циклического захвата ссылок? "Кто-нибудь" -- это очень мощный персонаж обычно

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

>> 2) Профи или не профи пишут внутренние библиотеки зависит от персонала.
V>О это еще что, а вот когда и буст не умеют и stl не умеют и С++ — это С
V>со структурами с методами (тьфу, классами). И такое бывает, видал и не раз.
V>Вот тогда чаще всего велосипеды и строят.

Но моё ИМХО, кстати такое, что даже это не критично. Это всё неприятно конечно, но обычно такой параметр, как "качество и поддерживаемость кода" зависит не от того "С с классами" или "STL с бустом", а от каких-то других характеристик кода.

В целом лично я скорее согласен иметь дело с хорошим кодом на "С с классами/структурами" или вообще просто на С, чем с плохим, с использованием любых самых продвинутых идей и средств

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

>> Ну а теперь читаем исходное сообщение
>> <http://rsdn.ru/forum/message/2631025.1.aspx&gt;

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

.>Я так и не понял что он не позволяет. Всё он позволяет, особенно в купе с weak_ptr. А "неэффективности" тоже ты
.>насочинял. Скажи чего там лишнего?

1) Про неэффективность по памяти писал не я.
2) ИМХО хуже не то, что он по памяти неэффективен, а то, что он не позволяет произвольно использовать код, в котором пользуются просто указатели. Хотя это всё решается конечно, но ценой усложнения то там, то сям.
Ну, например, просто указатели можно хранить как POD и особо не церемониться. С weak_ptr так уже не погоняешь...