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

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

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

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

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

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

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

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

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


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

Тем не менее, 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 и т.д.).
Для тех кому важно, чтобы реализация программы как можно ближе соответствовала ее модели, эти примитивы могут быть весьма полезными.

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

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


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


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

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

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

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

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

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






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

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

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

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

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

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

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

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

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