C++ Object Token Library

[Igors]

ты написал про совместное владение так, словно думаешь,
будто бы область применения shared - когда предполагается неколько владельцев.

на самом же деле, область применения shared - когда нужно расшаривать ресурс между несколькими потребителями.
количество владельцев при этом не суть важно.

важно, что если есть несколько потребителей, значит нужен shared.
и он будет. в том или ином виде.

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

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

Аналогия с "ресурсом" здесь неудачна/неуместна. Ресурс (напр icon) достаточно просто объявить shared, и все. Как уже подчеркивалось,  клиент (объект класса "A") НЕ владеет ссылкой (указателем на "B"), которая обычно активный объект (а вовсе не данные файла), может быть даже того же класса "A", и который может быть прибит хотя бы пользователем. Короче "один объект ссылается на другой" и никакими отношениями владения они в общем случае не связаны. Удивляет что Вы незнакомы с этой очень типовой ситуацией и считаете ее "каким-то багом".

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

Ну значит data не используется, ссылка разорвана. Это нормально, обычно "A" и конструируется с data = 0

[_Bers]

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

ты всерьёз думаешь, что кто-то придет на страничку с твоим проектом,
и увидев непойми что, станет тратить время на чтение непойми зачем?

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

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

про использование: если вам непонятна фраза "Using otn tokens is similar to using smart pointers from the C++ standard library." или вы не знаете, как пользоваться умными указателями стандартной библиотеки C++, то вам и токены вряд ли понадобятся.

вот ты пишешь:
"Using otn tokens is similar to using smart pointers from the C++ standard library."

пожалуй, это единственное предложение,
которое хоть как то проливает свет на предназначение библиотеки.

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

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

где примеры использования?

примеры использование - это первое, что должен увидеть твой потенциальный пользователь,
сразу же после фразы: "предназначение библиотеки..."

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

где документация на русском языке?

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

моё мнение опытного разработчика:
оформи материал по человечески.

сейчас твоя библиотека выглядит как непонятно что, не понятно зачем.

[_Bers]

ты написал про совместное владение так, словно думаешь,
будто бы область применения shared - когда предполагается неколько владельцев.

на самом же деле, область применения shared - когда нужно расшаривать ресурс между несколькими потребителями.
количество владельцев при этом не суть важно.

важно, что если есть несколько потребителей, значит нужен shared.
и он будет. в том или ином виде.

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

разница есть.

ты же пишешь так, будто бы если владелец предполагается только один,
тогда shared уже не нужен.
это - не верно.

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

Удивляет что Вы незнакомы с этой очень типовой ситуацией и считаете ее "каким-то багом".

может я не правильно понял, чего ты хочешь.
выше ты писал:

"A" при этом НЕ владеет data, не отвечает ни за его создание ни удаление. Естественно экземпляр A получает по рогам при стороннем удалении data, и это надо мучительно отслеживать.

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

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

но в таких случаях это нужно заранее оговаривать, Бро!
и пояснять что делать, если ресурса нет в наличии.

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

для подобной ситуации weak подходит идеально.

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

вот только как это коррелирует с какими то непонятными "токенами"?
какую проблему класса "А" они решают?

[Igors]

титульный лист - это трейлер к голивудскому блокбастеру.
...
и вот здесь мы вполную подходим к главной изюменке любого годного маркеттинга:
...

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

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

ты написал про совместное владение так, словно думаешь,
будто бы область применения shared - когда предполагается неколько владельцев.

на самом же деле, область применения shared - когда нужно расшаривать ресурс между несколькими потребителями.
количество владельцев при этом не суть важно.

Всякий shared - владелец, сделать его НЕ владельцем невозможно (как впрочем и заставить владеть монопольно). Если под "потребителем" имеется ввиду weak - надо так и говорить (а не наводить тень на плетень). Поэтому да, "область применения shared - когда предполагается несколько владельцев". Но это "по-хорошему", а сейчас его куда только ни суют за неимением лучшего.

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

Это момент "создания связи" где target (объект на который ссылаются) существовать обязан, поэтому проблем не возникает.

для подобной ситуации weak подходит идеально.

Нет, эта конструкция очень дырявая. Для того же простейшего примера. Во-первых, сделать "B" shared не так уж просто, ведь нужно чтобы юзер назначил эту связь, а значит "B" должен предъявляться в UI, иметь имя и.т.п. - какой уж тут shared. Значит придется шарить какие-то  внутренние данные "B", а тогда сразу огребем хотя бы при копировании "B". Чего и следовало ожидать: затыкать одну сущность другой плохо.

вот только как это коррелирует с какими то непонятными "токенами"?
какую проблему класса "А" они решают?

"If nothing could help - it's time to read doc"

[Авварон]

Всякий shared - владелец, сделать его НЕ владельцем невозможно (как впрочем и заставить владеть монопольно). Если под "потребителем" имеется ввиду weak - надо так и говорить (а не наводить тень на плетень). Поэтому да, "область применения shared - когда предполагается несколько владельцев". Но это "по-хорошему", а сейчас его куда только ни суют за неимением лучшего.

Я внезапно присоединюсь к _Bers (не думал что такой момент настанет) и попробую пояснить - автоматически "зануляющийся" указатель можно реализовать только связкой weak/shared по двум причинам. Первая в том, что weak требует своего отдельного счетчика ссылок, то есть это точно такой же refcount указатель как shared или COW классы. Даже QPointer реализован через QWeakPointer и QObject хранит внутри себя фейковую структуру SharedData от QSharedPointer (просто "основной" счетчик всегда -1). Вторая причина в том, что чтобы это потокобезопасно работало, надо уметь получать "сильную" ссылку, то есть shared_ptr. У weak_ptr нет метода .get() потому что он бесполезен! Просто проверка на отсутствие указателя условно полезна если вы хотите ничего не делать, или хотите делать, но указатель не нужен (сомнительная ситуация), если же надо что-то делать с указателем, то надо "стать владельцем" то есть вызвать .lock() (ака .toStrongRef())

Код:

if (weakPtr)
   foo(weakPtr.get()) // упс а тут уже nullptr

То есть условный QPointer применим только в однопоточном случае когда разраб "ниасилил" понять что там там где удаляется. Nuff said.

[Old]

Я внезапно присоединюсь к _Bers (не думал что такой момент настанет)

Скорее вы присоединились к здравому смыслу, потому что в том абзаце, на который вы отвечаете, написан фигня.
Igors так и не смог уяснить, что есть три понятия: ресурс, его владелец и пользователь ресурса, а умные указатели это средство управления этим хозяйством. Поэтому, глупо обсуждать эти механизмы в терминах "shared - владелец, а weak - нет", это разные уровни абстракции.

[Igors]

..автоматически "зануляющийся" указатель можно реализовать только связкой weak/shared по двум причинам.

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

чтобы это потокобезопасно работало, надо уметь получать "сильную" ссылку, то есть shared_ptr.

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

[_Bers]

Всякий shared - владелец, сделать его НЕ владельцем невозможно (как впрочем и заставить владеть монопольно). Если под "потребителем" имеется ввиду weak - надо так и говорить (а не наводить тень на плетень).

под "потребителем ресурса" я подразумею любого потребителя ресурса.

совершенно не важно, кем он является.
это может быть другой shared, weak, или обычный сырой указатель.

важно что он потребляет ресурс (хочет получать к нему доступ)

"область применения shared - когда предполагается несколько владельцев"

чувак не тупи.
вот с чего ты вообще это взял?

если у меня только 1 владелец, но множество потребителей,
мне ресурс шарить уже не нужно что ли?

как ты вообще себе представляешь доступ к одному ресурсу множества потребителей,
если при этом сам ресурс не расшарен?

Нет, эта конструкция очень дырявая. Для того же простейшего примера. Во-первых, сделать "B" shared не так уж просто, ведь нужно чтобы юзер назначил эту связь, а значит "B" должен предъявляться в UI, иметь имя и.т.п. - какой уж тут shared. Значит придется шарить какие-то  внутренние данные "B", а тогда сразу огребем хотя бы при копировании "B". Чего и следовало ожидать: затыкать одну сущность другой плохо.

я не понимаю, какое вообще отношение shared имеет к проблемам твоего UI

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

"If nothing could help - it's time to read doc"

ты даже не можешь сформулировать какая проблема решается.

[_Bers]

Скорее вы присоединились к здравому смыслу, потому что в том абзаце, на который вы отвечаете, написан фигня.

в каком таком "том" абзаце?

Поэтому, глупо обсуждать эти механизмы в терминах "shared - владелец, а weak - нет", это разные уровни абстракции.

я не понял, почему глупо?

shared - владелец.
weak -  не является владельцем ресурса.

и это - важный факты.

именно этим эти механизмы (отнюдь не абстрактные) и различаются.

[Old]

в каком таком "том" абзаце?

На который отвечал Аварон. Очевидно же.

[_Bers]

напр унаследоваться от shared и отрубить ему шаринг

я правильно тебя понял:
ты хочешь унаследоваться от shared, что бы отрубить шаринг?

это типа как...

унаследоваться от торговца, что бы отрубить ему торговлю?
унаследоваться от самолета, что бы отрубить ему возможность летать?

у тебя точно всё впорядке с логикой?

[ViTech]

Чем спорить, кто shared, а кто ресурс, я бы предложил составить UML диаграмму классов. Но кто ж будет заниматься такой ерундой .

[_Bers]

Чем спорить, кто shared, а кто ресурс, я бы предложил составить UML диаграмму классов. Но кто ж будет заниматься такой ерундой .

да не нужны никакие UML,
что бы понимать: shared - это механизм управления ресурсом, а не сам ресурс.

[Igors]

я правильно тебя понял:
ты хочешь унаследоваться от shared, что бы отрубить шаринг?

Совершенно правильно

это типа как...

унаследоваться от торговца, что бы отрубить ему торговлю?
унаследоваться от самолета, что бы отрубить ему возможность летать?

Да, именно так. Возможность летать мне не только не нужна, но даже вредит. Мне нужен только weak т.е. (хочу ползать ) возможность наблюдать не сдох ли. Зияющая дыра в std: почему я не могу получить weak от "юника"?  Это ведь никак не менее usable.

у тебя точно всё впорядке с логикой?

Абсолютно (чувачок)  

[ViTech]

да не нужны никакие UML,
что бы понимать: shared - это механизм управления ресурсом, а не сам ресурс.

Это даст общий знаменатель по терминам и семантике. Чтобы в одной сущности каждый не видел что-то своё (Слон и слепые мудрецы).