sab123 | shared

>> взять и опять положить изначальный указатель

А это разве не поперек идеологии RAII? Получил поинтер / хендл, засунь в смартпоинтер и убери руки. Брать и положить нельзя.

From:

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

From:

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

А где посмотреть как именно вы считаете рефкаунты?

From:

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

Вкратце описано оно здесь:

http://babkin-cep.blogspot.com/2012/08/reference-counting.html
http://babkin-cep.blogspot.com/2012/08/autoref-summary.html

И код тут:

http://sourceforge.net/p/triceps/code/HEAD/tree/trunk/cpp/mem/

From:

спасибо, почитаю.

From:

alll

Оно и так прекрасно ломается. Возьмёт кто-то достаточно упоротый raw указатель одновременно со smart и будет хранить его отдельно. Такие вещи в C++ пресекаются только на уровне coding policy/peer review/анализаторов кода.

From:

spamsink

Но если взять и опять положить изначальный указатель в другой твой Autoptr, то что будет?

From:

+1 к тому же счетчику.

From:

spamsink

Который где? Внутри объекта? А weak_ptr как делать?

Edited Date: 2014-05-03 06:30 am (UTC)

From:

Прямо в учитываемой структуре. Что гораздо лучше и надежнее, чем плодить счетчики отдельно.

From:

>> Прямо в учитываемой структуре

Я еще не читал, но это пахнет комом. Не то чтобы с комом что-то было не так, но все украдено до нас, и есть проблема с кольцевыми ссылками.

From:

alll

Так вроде у всех смарт-пойнтеров проблема с кольцевыми ссылками. Для её разруливания нужны weak-пойнтеры, которые вроде как тоже есть.

From:

в коме нету.

From:

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

From:

alll

Можно, но возможно не стоит. Слишком сильное ограничение, не всегда возможно соблюсти, ещё менее всегда можно навязать всей команде, сложно отловить анализаторами кода или в code review.

From:

В раельности оно почти всегда соблюдается. А когда не соблюдается, то дело сводится к делению объектов. То есть, например, есть у нас объекты A и B, которым надо ссылаться друг на друга. Более близкое изучение показывает, что на самом деле объекту B нужен не весь объект A, а только небольшая часть его. Выделяем эту часть в объект C. И в результате A ссылается на B и C, а B ссылается на C.

From:

Я про ком не читал, но свою версию я тоже не с пустого места придумал :-) Впрочем, как я уже написал ниже, главная проблема - то, что чтобы положить только что сконструированный объект в уже существующую ссылку, надо делать reset(ptr). Что способствует ошибочному деланию reset(ptr) и из прочих указателей. Если сделать указатели невидимыми, то reset(ptr) просто делается никогда не нужен и проблема уходит. Сделать их невидимыми можно или обернув конструкторы в статические функции, возвращающие ссылки, или всегда делать такое конструирование в два шага:

shared_ptr<Object> p = new Object;
somewhere->field_shared_ptr = p;

Ну, или в одну строчку

somewhere->field_shared_ptr = shared_ptr<Object>(new Object);
somewhere->field_shared_ptr = make_shared<Object>(new Object);

Edited Date: 2014-05-03 07:36 am (UTC)

From:

О, оказалось, что make_shared - это и есть такой готовый оборачивающий статический метод, который пропускает аргументы насквозь к конструктору.

From:

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

From:

Ну да, чтоб оно работало хорошо, надо C++11 - там темплейты могут пропускать насквозь аргументы, как через макро.

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

From:

ну, деференсирование там бесплатное
а передавать можно и реф на шейрд, там где копировать не нужно
я бустовые шейрды использую уже лет 10 наверное, даже если есть оверхед в 1-2%, это покрывается кастомными аллокаторами ну и просто тем что руками с памятью работать не нужно
кстати в майкрософте народ как-то умудрился оптимизировать shared_ptr, надо почитать, gcc'шная версия по крайней мере на 4.7 проигрывала

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

From:

Я в смысле, в сравнении с альтернативным вариантом, когда счетчик - прямо в объекте.

From:

А в чем проблема с weak_ptr? Ну, сделать его отдельным объектом. На который хранить ссылку в изначальном объекте. Он на самом деле вообще не очень-то и нужен.

Но вообще похоже, что я догадался, как надо делать с shared_ptr чтобы он не ломался: во всех классах, предназначенных для использования с ним, делать конструкторы защищенными, а вместо них использовать статические функции, которые будут возвращать сразу shared_ptr (возможно, делая make_shared, но непонятно, не делает ли он копирования объекта). И тогда простые указатели совсем исчезают, и сломать логику делается сложно.

From:

make_shared же и все дела
ой, ну да, дочитал :)
кстати. проблемы с оборачиванием одной и той же структуры в два шейрда ни разу не наблюдал

From:

Я за полчаса сумел :-) Но у меня, конечно, имеются рефлексы от другой методы счетчика.

From: