Russian Qt Forum
Апрель 19, 2024, 10:22 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 [2] 3 4 ... 9   Вниз
  Печать  
Автор Тема: C++ Object Token Library  (Прочитано 52225 раз)
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #15 : Февраль 08, 2020, 13:03 »

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

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

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

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

допустим ты решил использовать невладеющий weak.
тогда у тебя на руках окажется невалидный weak, и как это тебе поможет?
Ну значит data не используется, ссылка разорвана. Это нормально, обычно "A" и конструируется с data = 0
Записан
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #16 : Февраль 08, 2020, 13:27 »

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

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

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

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

про использование: если вам непонятна фраза "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
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #17 : Февраль 08, 2020, 13:58 »

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #18 : Февраль 08, 2020, 15:12 »

титульный лист - это трейлер к голивудскому блокбастеру.
...
и вот здесь мы вполную подходим к главной изюменке любого годного маркеттинга:
...
Наверное "вплотную", "изюминке" и "маркетинга". Но, насколько я вижу, автор вовсе не стремится сделать это бестселлером, вещь вообще некоммерческая. Да, наверно стоит немного больше сказать "взагал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" Улыбающийся
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3258


Просмотр профиля
« Ответ #19 : Февраль 08, 2020, 16:21 »

Всякий 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
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4349



Просмотр профиля
« Ответ #20 : Февраль 08, 2020, 16:48 »

Я внезапно присоединюсь к _Bers (не думал что такой момент настанет)
Скорее вы присоединились к здравому смыслу, потому что в том абзаце, на который вы отвечаете, написан фигня. Улыбающийся
Igors так и не смог уяснить, что есть три понятия: ресурс, его владелец и пользователь ресурса, а умные указатели это средство управления этим хозяйством. Поэтому, глупо обсуждать эти механизмы в терминах "shared - владелец, а weak - нет", это разные уровни абстракции.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #21 : Февраль 08, 2020, 16:51 »

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

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

Сообщений: 486


Просмотр профиля
« Ответ #22 : Февраль 08, 2020, 16:55 »

Всякий 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
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #23 : Февраль 08, 2020, 16:57 »

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

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

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

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

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

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

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

« Последнее редактирование: Февраль 08, 2020, 17:01 от _Bers » Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4349



Просмотр профиля
« Ответ #24 : Февраль 08, 2020, 17:06 »

в каком таком "том" абзаце?
На который отвечал Аварон. Очевидно же.
Записан
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #25 : Февраль 08, 2020, 17:08 »

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

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

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

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

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


Записан
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #26 : Февраль 08, 2020, 17:26 »

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

Пока сам не сделаешь...
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #27 : Февраль 08, 2020, 17:28 »

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

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

Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #28 : Февраль 08, 2020, 17:32 »

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

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

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

у тебя точно всё впорядке с логикой?
Абсолютно (чувачок)  Улыбающийся
Записан
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #29 : Февраль 08, 2020, 17:37 »

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

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

Пока сам не сделаешь...
Страниц: 1 [2] 3 4 ... 9   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.123 секунд. Запросов: 22.