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

P>Попробую обобщить – имеются 2 типа указателей. Первый тип это совместное владение, второй снабжение указателя информацией об разрушении. Может быть так что объект содержится внутри другого объекта или контейнера, который сам заботится об удалении и тогда сильные не нужны. Для обоих типов есть 2 подхода – либо объект знает про указатели либо нет. Знание объекта об указателях более надежно, с другой стороны мы можем не иметь возможности менять тип объекта, если коды не наши. Да и классы могут быть какието общеупотребительные, в которых лишнее не желательно Например такие простые как CPoint или даже целое л-валуе.

С чужими классами никаких проблем нет — они не могут держать в себе ссылки на наши объекты. Если у них есть встроенный счетчик ссылок — применяем intrusive_ptr, если нет — shared_ptr. Оверхед, связанный с shared_ptr, во втором случае неизбежен, так как память под счетчик выделять-то где-то надо.

P>boost::shared_ptr однозначно требует алокации счетчика. enable_shared_from_this просто регистрирует его. В частности

Requires: enable_shared_from_this<T> must be an accessible base class of T. *this must be a subobject of an instance t of type T . There must exist at least one shared_ptr instance p that owns t.

Думаю сделать shared_ptr с возможностями добавлять enable_intrusive_from_this и enable_weak_from_this былобы правильней. Узнать об разрушении объекта ведь можно ведь не только из деструктора владеющего указателя, но из деструктора самого объекта.

Это как? Ведь для того, чтобы weak_ptr был в принципе возможен, отдельно от объекта в памяти должен висеть какой-то объект, который будет регистрировать смерть объектов — то, что Erop в соседней ветке называл прокси или например shared_count от shared_ptr. Так что никакой возможности сэкономить new/delete или хотя бы несколько байт я тут не вижу.

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

S>С чужими классами никаких проблем нет — они не могут держать в себе ссылки на наши объекты. Если у них есть встроенный счетчик ссылок — применяем intrusive_ptr, если нет — shared_ptr. Оверхед, связанный с shared_ptr, во втором случае неизбежен, так как память под счетчик выделять-то где-то надо.

Оверхед всегда избежен
От чужих можно отнаследовать и внедрить счётчик. Либо выделять памяти sizeof(T) + sizeof(int), и класть перед объект счётчик (что в общем-то примерно то же самое только более хакерски ).

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

J>>А в реальности бывает, что те, кто писал изначально, давно уволились, а из вновь пришедших никто ничего в архитектуре этой библиотеки не понимает. И вся дальнейшая разработка превращается в тупой баг-фикс и копи-пейст.
E>Ты не знаешь продуктов, которые пережили более 5 версий?
E>MS Word
E>Adobe Photoshop
E>Mac OS
E>OmniPage
E>The Bat
E>gcc правда пока только 4 версии пережил, но есть таки надежда
E>1С
E>WinDVD Pro
E>Nero
E>Lingvo
E>Даже "Герои меча и магии" кажется уже 5 версий набрали (если с KingsBounty считать )

Я тоже знаю продукт, переживший 5 версий — 3dsMax Вот только брать его как пример удачной реализации совершенно нельзя, скорее — наоборот.
Там какраз проявляются проблемы того, что кто-то написал, а потом ушёл. Новые программисты решают теже самые вопросы, но уже по-другому.
А тем, кто пишет под него плагины, приходится разбираться со всеми этими "решениями". От которых зачастую просто мутит.

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

E>Да? Ну, например, параметры шаблона не передаются рекусивно.
E>Скажем так написать нельзя:

template<class T> myData { std::vector<T> data; };

E>Скажут, что T не определён
Вот тебе в качестве контрпримера цитата из стандарта (23.2.3.1)

namespace std {
 template <class T, class Container = deque<T> >
 class queue {
  ...
  Container c;
  ...
 };
}

Найди десять отличий

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

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

P>boost::shared_ptr однозначно требует алокации счетчика. enable_shared_from_this просто регистрирует его. В частности

Requires: enable_shared_from_this<T> must be an accessible base class of T. *this must be a subobject of an instance t of type T . There must exist at least one shared_ptr instance p that owns t.

Думаю сделать shared_ptr с возможностями добавлять enable_intrusive_from_this и enable_weak_from_this былобы правильней. Узнать об разрушении объекта ведь можно ведь не только из деструктора владеющего указателя, но из деструктора самого объекта.

enable_shared_from_this — это просто базовый класс, хранящий внутри weak_ptr и инициализирующий его this-ом в своем конструкторе. Так что enable_weak_from_this уже есть .

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

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

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

S>>Хотя последнее время приходится много на этом c++/cli программировать. Хорошо, что хоть не на C# .
WH> C++/CLI хорошо подходит только для нетривиального интеропа с кодом на С/С++.
Именно для этого он и используется — для того, чтобы вызывать сложные геометрические процедуры (С++) из приложения на C#.

> S>С чужими классами никаких проблем нет — они не могут держать в себе ссылки на наши объекты. Если у них есть встроенный счетчик ссылок — применяем intrusive_ptr, если нет — shared_ptr. Оверхед, связанный с shared_ptr, во втором случае неизбежен, так как память под счетчик выделять-то где-то надо.
>
> Оверхед всегда избежен
> От чужих можно отнаследовать и внедрить счётчик. Либо выделять памяти sizeof(T) + sizeof(int), и класть перед объект счётчик (что в общем-то примерно то же самое только более хакерски ).

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

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

WH> C++/CLI хорошо подходит только для нетривиального интеропа с кодом на С/С++.
WH>Использовать его для основной разработки глупость.

Можно тут поподробнее

> И вообще не вижу никакого волшебства в enable_shared_from_this. Ведь чтобы его использовать, надо наследоваться. Почему счетчик внутренним не сделать в этом случае?

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

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

>> И вообще не вижу никакого волшебства в enable_shared_from_this. Ведь чтобы его использовать, надо наследоваться. Почему счетчик внутренним не сделать в этом случае?

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

Вариант первый.
Объединить все shared/weak ptr'ы в список, тогда можно будет нотифицировать weak ptr'ы об удалении/создании объекта.

Вариант второй.
Разместить счётчик перед объектом в памяти.

>>> И вообще не вижу никакого волшебства в enable_shared_from_this. Ведь чтобы его использовать, надо наследоваться. Почему счетчик внутренним не сделать в этом случае?
>
> S>Предложите ваш механиз реализации weak_ptr для классов с внутренним счетчиком (но только чтоб без отдельно висящих в памяти флажков, проксей и т.п.). Если у вас это получится, все, кого волнует производительность, на него быстро-быстро переползут (и я в первых рядах).
>
> Вариант первый.
> Объединить все shared/weak ptr'ы в список, тогда можно будет нотифицировать weak ptr'ы об удалении/создании объекта.

Не подходит. Придется выделять память для элементов списка.

> Вариант второй.
> Разместить счётчик перед объектом в памяти.

А какая разница — перед или где-то еще? Убивать то его все равно надо отдельно от убиения объекта. Хотя, если поизвращаться с placement new и ручным вызовом деструктора, то может чего-нибудь и получиться. Правда, будет неоптимально по памяти при наличии слабых ссылок. Можно попробовать...

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

>> Вариант первый.
>> Объединить все shared/weak ptr'ы в список, тогда можно будет нотифицировать weak ptr'ы об удалении/создании объекта.

S>Не подходит. Придется выделять память для элементов списка.
Не обязательно. Можно соорудить что-то вроде linked_ptr.

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

>>>> И вообще не вижу никакого волшебства в enable_shared_from_this. Ведь чтобы его использовать, надо наследоваться. Почему счетчик внутренним не сделать в этом случае?
>>
>> S>Предложите ваш механиз реализации weak_ptr для классов с внутренним счетчиком (но только чтоб без отдельно висящих в памяти флажков, проксей и т.п.). Если у вас это получится, все, кого волнует производительность, на него быстро-быстро переползут (и я в первых рядах).
>>
>> Вариант первый.
>> Объединить все shared/weak ptr'ы в список, тогда можно будет нотифицировать weak ptr'ы об удалении/создании объекта.

S>Не подходит. Придется выделять память для элементов списка.

Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.


>> Вариант второй.
>> Разместить счётчик перед объектом в памяти.

S>А какая разница — перед или где-то еще? Убивать то его все равно надо отдельно от убиения объекта. Хотя, если поизвращаться с placement new и ручным вызовом деструктора, то может чего-нибудь и получиться. Правда, будет неоптимально по памяти при наличии слабых ссылок. Можно попробовать...

Тут идея, что weak ptr'ы будут жить ограниченное время после самого объекта, либо их ограниченное кол-во.

> S>Не подходит. Придется выделять память для элементов списка.
>
> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.

Кроме производительности. А формально — да, подходит.

> S>А какая разница — перед или где-то еще? Убивать то его все равно надо отдельно от убиения объекта. Хотя, если поизвращаться с placement new и ручным вызовом деструктора, то может чего-нибудь и получиться. Правда, будет неоптимально по памяти при наличии слабых ссылок. Можно попробовать...
>
> Тут идея, что weak ptr'ы будут жить ограниченное время после самого объекта, либо их ограниченное кол-во.

Ну да, для некоторых применений подойдет.

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

V>Не в именах сложность, имена бог с ними. В любом случае контейнеры будут typedef-ица, ListSomeObj там ContainerSomeObj.. другое дело, что будете пользоваться разработанными концепциями. STL предлогает не только контейнеры, но хорошую поддержку этих контейнеров как в алгоритмах, так в адаптации собственных. А ты говориш sort, merge... Мне просто адцки любопытно было бы посмотреть весь ваш фреймворк, который заменяет собой хотябы тот же STL и часть буста (а не сугубо специфические библиотеки) в сравнении ними же. Вообщем.. ниже.

У нас есть массивы, списки, деревья, мнодества и отображения. Их можно сортировать и осуществять над ними двухпутевое сляиение, кроме того в них можно искать бинарно или линейно. Существенным отличием массивов от STLных является то, что они могут хранить некопируемые, ноперемещаемые объекты.
Кроме того есть несколько типов массивов, которых нет в STL. Например, есть массив, который хранит данные {1, 2, 2, 2, 3, 3, 3, 1, 1 } так: { 1(1 раз), 2(3 раза), 3(3 раза), 1(2 раза) }, позволяя итерировать объекты как по одному, так и по группам.

Есть умные указатели (интрузивный со счётчиком и некопируемый эксклюзивный). Есть поддержка полиморфной сериализации и RTTI создания объектов. Очень сильно отличается работа с памятью. В управлении памятью используются совсем другие принципы, чем в STL, например.

V>А нафига? По твоим постам я понял, у тебя свободного времени просто тонна и ты не знаешь как по извратнее бы его потратить.
Не знаю я, что такое "поизвратнее". Одна из текущих задач, стоящих перед моей группой звучит так: "Разработать лучший в мире ХХХ, с беспрецедентно высоким качеством YYY". На это можно потратить всё свободное и несвободное время. И STL и boost тут не помогут, увы

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

Ну а если тебе реально интересно посмотреть на наш фреймворк, то надо просто пройти собеседование и попасть в отдел исследований и разработок

V>Всегда есть Свои лидеры есть везде.. Я вот тут подумал, а почему бы вам не разработать свой язык и не написать свой компилятор?
Ну программисты, которые поддерживали фреймворк менялись неоднократно, а фреймворк от этого принципиально не сменился. Просто развился несколько.

E>>Ну брать библиотеки "по частям", особенно если они нифига не сегментированы на них, или писать свои -- работа, ИМХО, примерно олинаковая. Только во втором случае ты менешь зависишь от неконтролируемых факторов...
V>А что ты считаешь контроллируемым фактором? Как раз таки стандартные средства более контролируемый фактор. Их используют все. Поэтому они меньше подвержены флуктуациям.

Контролируемым фактором я считаю планирование производимых работ и хорошее ими управление. А ты значит надеешься на флюктуации? Ну-ну

V>Вы случайно не велосипеды выпускаете?
Мы случайно учимся быть взаимовежливыми.
А у вас оборт по торговле ПО хотя бы $10 000 000 сулчайно превосходит?

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

>> S>Не подходит. Придется выделять память для элементов списка.
>>
>> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.

S>Кроме производительности. А формально — да, подходит.

А какие проблемы с производительностью?

>>> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.
>
> S>Кроме производительности. А формально — да, подходит.
>
> А какие проблемы с производительностью?

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

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

J>Что там поддерживать?
J>Вот лежит себе буст, никого не парит.
J>Есть четкие указания, что из него можно использовать А, Б и В, остальное либо нельзя либо после предварительных консультаций.
J>В чем проблема-то?

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

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

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

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

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

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

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

E>>>>>>

---

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

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

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

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

M>Я тоже знаю продукт, переживший 5 версий — 3dsMax ...
M>А тем, кто пишет под него плагины, приходится разбираться со всеми этими "решениями". От которых зачастую просто мутит.

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

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

E>>Да? Ну, например, параметры шаблона не передаются рекусивно.
J>Вот тебе в качестве контрпримера цитата из стандарта (23.2.3.1)
Ну да "стнадарт от такого-то года поддержен не полностью"... И живи как хочешь.