C++ Object Token Library

[ViTech]

C++ Object Token Library - это эволюция Unified Pointer Library из этой темы.

Основные изменения:

• Терминология: pointer -> object token.
• Все токены по умолчанию single, а не optional.
• Удалён safe::weak_single.
• Добавлен slim::unique (обёртка над std::unique_ptr).
• Добавлены raw::weak, raw::unified (обёртки над голым указателем).
• Функции для унифицированного доступа к токенам.
• Traits.
• Что-то ещё .

[ssoft]

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

После беглого просмотра осталось несколько вопросов:

- Токены реализуют только ассоциативные связи агрегации?
- Экземпляры, которыми владеют/ссылаются токены, всегда формируются в куче?
- Можно ли связать токены и произвольную переменную?
- Можно ли связать токены и произвольный параметр?

[ViTech]

- Токены реализуют только ассоциативные связи агрегации?

Текущий набор токенов предназначен в основном для выражения ассоциативных связей и написания программ в стиле ООП. Но можно применять и в функциональном программировании, с учётом понимания особенностей токенов. Кроме того, можно добавлять типы токенов не связанных с ассоциативными связями. У меня есть идеи для таких токенов, но пока у меня нет в них надобности, я их и не делал.

- Экземпляры, которыми владеют/ссылаются токены, всегда формируются в куче?

Сейчас владеющие токены да, только для объектов в куче. raw::weak/raw::unified могут ссылаться на объекты на стеке. Про владеющие токены для объектов на стеке нужно думать отдельно, чтобы поведение токенов было согласованным. Основные проблемы возникают при перемещении объекта.

- Можно ли связать токены и произвольную переменную?
- Можно ли связать токены и произвольный параметр?

Не совсем понял эти вопросы, хорошо бы привести примеры . raw::weak/raw::unified можно связать со всем, что имеет адрес. Под свою ответственность разумеется .

В целом, не нужно пугаться этих заумных слов про ассоциативные связи, агрегации, UML и прочее. Токены из CppOtl - это аналог умных и голых указателей С++, с расширенными возможностями. Поэтому в первой библиотеке Unified Pointer Library они указателями и назывались .

[_Bers]

не очевидно, нафига нужна эта библиотека.

[ViTech]

не очевидно, нафига нужна эта библиотека.

Если вы прочитали всё документацию по ссылке и не нашли ничего полезного для себя, значит вам она не нужна. Что не отменяет факта её возможной полезности для других людей .

[Igors]

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

Не сказал бы, лично к меня "токен" стойко ассоциируется со строками и синтаксическим разбором.

Что не отменяет факта её возможной полезности для других людей .

Ну кол-во пользователей Вашей библиотеки всегда будет исчисляться простым натуральным числом Это проблема ЛЮБОГО велика - да, возможно он решает насущные проблемы, и совсем не исключено что намного лучше чем занюханная стандартная библиотека. НО дальше этого он никуда не пойдет. Поясняю на живом примере:

Вот Вы стали бы использовать МОЙ код? Думаю что НИКОГДА, даже без разницы чему он посвящен. Потому что Вы же пишете (намного) лучше, знаете (намного) больше и.т.п Да и чисто объективно обычно лучше "подсмотреть идею" чем пристраивать посторонку. А вот std - да, использовать будут, даже если полный кал - но стандартный, и это мощнейшая отмазка, которой у Вас, увы, нет. Если человек работает в проекте вместе с Вами, то std код катит, а вот самопал - себе дороже. Не обязан человек его знать/учить, а вот (сраное) std - обязан.

Думаете кто-то рассуждает иначе? Вот ssoft относится к Вашей затее весьма позитивно и конструктивно, спросите у него задействует ли он эту либу в своем проекте? Конечно могу лишь предполагать, но думается ответ будет типа "все не так просто" - и это нормально

[ViTech]

Не сказал бы, лично к меня "токен" стойко ассоциируется со строками и синтаксическим разбором.

Токен вообще много к чему приплетают . В UML пишут про object token, оттуда и пошло.

Ну кол-во пользователей Вашей библиотеки всегда будет исчисляться простым натуральным числом Это проблема ЛЮБОГО велика - да, возможно он решает насущные проблемы, и совсем не исключено что намного лучше чем занюханная стандартная библиотека. НО дальше этого он никуда не пойдет. Поясняю на живом примере:

Вот Вы стали бы использовать МОЙ код? Думаю что НИКОГДА, даже без разницы чему он посвящен. Потому что Вы же пишете (намного) лучше, знаете (намного) больше и.т.п Да и чисто объективно обычно лучше "подсмотреть идею" чем пристраивать посторонку. А вот std - да, использовать будут, даже если полный кал - но стандартный, и это мощнейшая отмазка, которой у Вас, увы, нет. Если человек работает в проекте вместе с Вами, то std код катит, а вот самопал - себе дороже. Не обязан человек его знать/учить, а вот (сраное) std - обязан.

Думаете кто-то рассуждает иначе? Вот ssoft относится к Вашей затее весьма позитивно и конструктивно, спросите у него задействует ли он эту либу в своем проекте? Конечно могу лишь предполагать, но думается ответ будет типа "все не так просто" - и это нормально.

Использование сторонней библиотеки всегда риск. Эту библиотеку я делаю для себя. Мне важно, чтобы я мог использовать такую функциональность в проектах, в которых я принимаю участие. И мне не жалко поделиться этими наработками с другими. Чтобы показать, что на С++ можно писать вот так, с меньшими страданиями . Если на её основе сделают что-то покруче, так на здоровье. Будут ли ей пользоваться другие, меня уже меньше волнует. Как говорится: моё дело предложить .

Ну а пока напомню, что gsl::not_null<std::unique_ptr> до сих пор не работает. А на днях из gsl::not_null удалили конструктор перемещения (нашёл этот pull request). Похоже, у них своё видение not_null семантики. И std::observer_ptr в C++20 так и не вошёл, насколько я понял. И что-то я не вижу подвижек на этом поле в сторону выразительности умных и не очень указателей. Если кто знает такие - сообщайте.

[ssoft]

Не сказал бы, лично к меня "токен" стойко ассоциируется со строками и синтаксическим разбором.

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

Код:

int value = 1;

int - тип, 1 - значение, value - токен, с помощью которого можно осуществить доступ к значению 1. При этом в зависимости от места записи, value может являться свойством (property), параметром (parameter) или переменной (variable).

Вот ssoft относится к Вашей затее весьма позитивно и конструктивно, спросите у него задействует ли он эту либу в своем проекте? Конечно могу лишь предполагать, но думается ответ будет типа "все не так просто" - и это нормально

Действительно, реализация мне интересна больше с академической точки зрения, но только потому, что я не разделяю идею использования аналога указателей в качестве токенов. Основной причиной считаю, что указатель является семантически неверным с точки зрения модели ООП. Но огромное количество разработчиков даже не думает об этом (не забивают себе мозг всякой ерундой  ) - используют всё, что есть под рукой, совершенно не задумываясь об ассоциативных связях, согласованности и непротиворечивости объектно-ориентированной модели.

Тем не менее, C++ Object Token Library достаточно близка по виду к умным указателям std, при этом дополнительно решает ряд задач:

- корректно согласует модельное понятие агрегации shared, composite, none (shared, unique, weak) с технически механизмом продления жизни;
- обеспечивает гарантированную мультипликативность (single, optional);
- ликвидирует необходимость прямой работы с нативными указателями.

По виду указателя нельзя однозначно определить, что из себя он представляет - значение, массив, ассоциативная связь. Умные указатели std - это одно из частных решений для замены нативных, не всегда удобное, так как добавляет ряд свойств и ограничений применения (memory heap, optional и др.).

Реализация C++ Object Token Library добавляет механизмы управления такими свойствами, как (single/optional, продление времени жизни), но не такими как (thread safe, lazy/cow и т.д.).
Для тех кому важно, чтобы реализация программы как можно ближе соответствовала ее модели, эти примитивы могут быть весьма полезными.

[Авварон]

ssoft
Красиво заливаете, кажется, стоит посмотреь этого зверя

[ViTech]

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

Код:

int value = 1;

int - тип, 1 - значение, value - токен, с помощью которого можно осуществить доступ к значению 1. При этом в зависимости от места записи, value может являться свойством (property), параметром (parameter) или переменной (variable).

Самое интересное, что в UML токен объекта описан в общих чертах:
15.2.3.1 Activities (UML)

Tokens are not explicitly modeled in an Activity, but are used for describing the execution of an Activity. An object token is a container for a value that flows over ObjectFlow edges (some object tokens can flow over ControlFlow edges, as specified by the modeler, see isControlType for ObjectNodes in sub clause 15.4). An object token with no value in it is called a null token.

Т.е. токен объекта - это контейнер, и моделируйте/реализуйте его как хотите .

Тем не менее, C++ Object Token Library достаточно близка по виду к умным указателям std, при этом дополнительно решает ряд задач:

- корректно согласует модельное понятие агрегации shared, composite, none (shared, unique, weak) с технически механизмом продления жизни;
- обеспечивает гарантированную мультипликативность (single, optional);
- ликвидирует необходимость прямой работы с нативными указателями.

По виду указателя нельзя однозначно определить, что из себя он представляет - значение, массив, ассоциативная связь. Умные указатели std - это одно из частных решений для замены нативных, не всегда удобное, так как добавляет ряд свойств и ограничений применения (memory heap, optional и др.).

Реализация C++ Object Token Library добавляет механизмы управления такими свойствами, как (single/optional, продление времени жизни), но не такими как (thread safe, lazy/cow и т.д.).
Для тех кому важно, чтобы реализация программы как можно ближе соответствовала ее модели, эти примитивы могут быть весьма полезными.

Спасибо за отзыв .

Действительно, реализация мне интересна больше с академической точки зрения, но только потому, что я не разделяю идею использования аналога указателей в качестве токенов. Основной причиной считаю, что указатель является семантически неверным с точки зрения модели ООП. Но огромное количество разработчиков даже не думает об этом (не забивают себе мозг всякой ерундой  ) - используют всё, что есть под рукой, совершенно не задумываясь об ассоциативных связях, согласованности и непротиворечивости объектно-ориентированной модели.

Я, кстати, тоже не разделяю идею использования аналога указателей в качестве токенов . Об этом говорится в разделе Access. То, что сейчас токены внутри реализованы через указатели, не значит, что токены - тоже указатели. Хотя имеют их черты. Просто привожу аналогию с умными указателями std чтобы сразу было примерно понятно, что это за штуковины .

[_Bers]

не очевидно, нафига нужна эта библиотека.

Если вы прочитали всё документацию по ссылке и не нашли ничего полезного для себя, значит вам она не нужна. Что не отменяет факта её возможной полезности для других людей .

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

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

вот например:
https://github.com/zeux/pugixml

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

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

[ViTech]

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

Вам низачем и никак.

[Igors]

в твоём случае оформление убогое.

Как быстро срабатывает рефлекс "велик, костыль"

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

Пример: до боли простая задача/ситуевина

Код

C++ (Qt)
struct A {
 ...
 B * data;
 ...
};  

"A" при этом НЕ владеет data, не отвечает ни за его создание ни удаление. Естественно экземпляр A получает по рогам при стороннем удалении data, и это надо мучительно отслеживать. Чтобы автоматом иметь валидность data приходится объявлять его weak, а сами данные создавать shared, никаких др стандартных средств нет. В итоге получается/навязывается липовый shared, ведь никакого совместного владения этими данными не планировалось. Задумка автора (насколько я понимаю) создать такую серию вумных указателей чтобы "легализовать" такое (и др) отношения использлвания.

Использование сторонней библиотеки всегда риск. Эту библиотеку я делаю для себя. Мне важно, чтобы я мог использовать такую функциональность в проектах, в которых я принимаю участие. И мне не жалко поделиться этими наработками с другими. Чтобы показать, что на С++ можно писать вот так, с меньшими страданиями . Если на её основе сделают что-то покруче, так на здоровье. Будут ли ей пользоваться другие, меня уже меньше волнует. Как говорится: моё дело предложить .

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

Кстати за истекшее время я реализовал свою "фишку" (в первую очередь для решения проблемы выше). У меня получилась статУя вообще без всяких указателей/токенов. Т.е. для примера выше члена data просто нет. Вместо этого используется обращение к глобальной "таблице связей" между объектами. Однако это уже за рамками темы 

[_Bers]

в твоём случае оформление убогое.

Как быстро срабатывает рефлекс "велик, костыль"

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

причем тут какие то рефлексы?

выше я приводил пример качественно оформленной библиотеки pugixml.
на самом деле подобных примеров масса.

вполне себе велосипед:
https://github.com/USCiLab/cereal

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

Пример: до боли простая задача/ситуевина

Код

C++ (Qt)
struct A {
 ...
 B * data;
 ...
};  

"A" при этом НЕ владеет data, не отвечает ни за его создание ни удаление. Естественно экземпляр A получает по рогам при стороннем удалении data, и это надо мучительно отслеживать. Чтобы автоматом иметь валидность data приходится объявлять его weak, а сами данные создавать shared, никаких др стандартных средств нет. В итоге получается/навязывается липовый shared, ведь никакого совместного владения этими данными не планировалось. Задумка автора (насколько я понимаю) создать такую серию вумных указателей чтобы "легализовать" такое (и др) отношения использлвания.

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

однако очевидно, что сама по себе такая ситуация - это какой то баг

2.
это - баг безотносительно к тому, использовал ты raw pointer, или связку shared/weak

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

тебе ресурс нужен, а его нет.
нужно звать программистов и чинить программу.

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

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

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

4.
я не понял, какое "такое" использование?
какая вообще проблема решается?

[ViTech]

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

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

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