weak_ptr from intrusive, свой велосипед Опции

[alexy]

shared_ptr нельзя создать в конструкторе...
у меня сейчас в многопоточном коде часто появляются двухэтапные конструкторы. снчала создаешь shared_ptr потом вызываешь какой-нибудь registr или еще что-нибудь, куча отложенных созданий объектов, когда я бы мог создать его в конструкторе ,но создаю в фукнции ,которой он нужен, из-за этого появляются дополнительные проверки "не создал ли я его уже?", которых можно было бы избежать, если бы...
к тому же мне не нравится shared_from_this с точки зрения ООП, это как бы деталь реализации, закравшаяся в интерфейс.

может спасти intrusive_ptr, но у него нет weak_ptr и значит проблема циклических ссылок будет.

вобщем сегодня я накатал такой код. не уверен в правильности использвания std::atomic. выбрал shared_ptr для быстроты реализации. потом хочу сделать структуру, одно поле будет счетчиком ссылок для объекта, другое для weak_ptr'а.

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

зы: а что, нельзя загружать файлы hpp ??

Прикрепленные файлы

 intrusive_weak_ptr.hpp.txt ( 3.67 килобайт ) Кол-во скачиваний: 396

 

[Iron Bug]

а зачем делать

auto sptr_ = new foo();
std::shared_ptr<foo> sptr = sptr_->get_shared();

если нужно делать сразу

std::shared_ptr<foo> sptr = shared_ptr<foo>(new foo());

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

[alexy]

если нужно делать сразу

std::shared_ptr<foo> sptr = shared_ptr<foo>(new foo());

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

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


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

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

// плохо, если some_spin - raw pointer
int val = some_spin->value();
// тут другой поток убивает родителя...
if(!do_somthis(val)) some_spin->value(0);

а weak_ptr'а нет, если иметь дело с raw pointer