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 килобайт ) Кол-во скачиваний: 425

 

[lanz]

а чем лучше?

Separation of concerns, разделяете тип хранения (shared_ptr), реестры и ваш класс. Тип хранения это деталь реализации.
Вот например сейчас у вас один реестр, а захотите например 2, из которых один записывает в БД. Добавляете новую фабрику, с 2 реестрами и все. Хотите создаете с одним реестром, хотите с двумя. А если у вас занесение в реестр в конструкторе как вы это реализуете? параметр передавать в конструктор? if-then-else?

а если я хочу указатель на созданный тип, а не на базовый?

Interface segregation principle, значит у базового типа плохой интерфейс, возможно стоит сделать еще один?
Если не хочется много писать, сделайте factory template:

template <typename T>
class MySharedFactory {
  std::shared_ptr<T> create() { return std::shared_ptr<T>(new T); }
}

[alexy]

Separation of concerns, разделяете тип хранения
...
Interface segregation principle, значит у базового типа плохой интерфейс, возможно стоит сделать еще один?

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

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

ЗЫ: да, мои гуглинья наводят меня на мысль, что это действительно никому не нужно и люди юзают другие способы. выходит что обычно такое рашется именно фабрикой?