Делаю такую штуку. Может ещё кому пригодится.

Unified Pointer Library (описание на русском) — библиотека унифицированных указателей (UPL), содержит концепты и реализации умных указателей, которые предназначены для управления временем жизни объектов. Предоставляет указатели upl::unique и upl::shared для уникального и совместного владения объектами, слабые ссылки для них upl::weak, и добавляет унифицированный тип владения upl::unified. Публичный интерфейс унифицированных указателей схож с интерфейсом умных указателей стандартной библиотеки C++.

Ключевые особенности:

• Возможность организации ассоциативных связей между объектами в соответствии с UML.
  
• Определены концепты, которые в compile-time позволяют гибко определять тип указателей UPL в обобщённых алгоритмах.
  
• Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.
  
• Указатель upl::unified позволяет передать уникальное владение объектом в цепочке, где может выполняться копирование.
  
• С помощью upl::unified можно временно продлить время жизни объекта в заданной области видимости, что позволяет корректно завершить работу с ним, даже когда все остальные указатели на этот объект удалены.
  
• Добавлены указатели с одинарной кратностью, которые не могут быть пустыми и всегда ссылаются на один объект.

Библиотека header-only, лицензия MIT.

Здравствуйте, ViTech, Вы писали:

VT>Делаю такую штуку. Может ещё кому пригодится.

VT>Unified Pointer Library (описание на русском) — библиотека унифицированных указателей (UPL), содержит концепты и реализации умных указателей, которые предназначены для управления временем жизни объектов. Предоставляет указатели upl::unique и upl::shared для уникального и совместного владения объектами, слабые ссылки для них upl::weak, и добавляет унифицированный тип владения upl::unified. Публичный интерфейс унифицированных указателей схож с интерфейсом умных указателей стандартной библиотеки C++.

Круто! Ждём Unified Math Library, Unified GUI Libaray и Unified Coroutine and Threading Library.

Здравствуйте, ViTech, Вы писали:

VT>Делаю такую штуку. Может ещё кому пригодится.

VT>Unified Pointer Library (описание на русском) — библиотека унифицированных указателей (UPL), содержит концепты и реализации умных указателей, которые предназначены для управления временем жизни объектов. Предоставляет указатели upl::unique и upl::shared для уникального и совместного владения объектами, слабые ссылки для них upl::weak, и добавляет унифицированный тип владения upl::unified. Публичный интерфейс унифицированных указателей схож с интерфейсом умных указателей стандартной библиотеки C++.

какие проблемы решались при создании библиотеки, которые не могут решить стандартные указатели?

Здравствуйте, night beast, Вы писали:

NB>какие проблемы решались при создании библиотеки, которые не могут решить стандартные указатели?

Теоретическая основа:

Целью проекта UPL является создание инструментальной библиотеки для повышения качества и удобства программирования на языке C++ в стиле ООП, в частности для организации ассоциативных связей между объектами в многопоточной среде.

Введение:

UPL предоставляет расширенную семантику для концепций владения и управления временем жизни объектов, по сравнению с умными указателями стандартной библиотеки C++. Больше внимания уделяет указателям с уникальным владением (слабые ссылки для них, возможность передачи в функторы, которые требуют копирование аргументов (std::function)), обеспечивает продление времени жизни объекта в заданной области видимости, добавляет указатели с одинарной кратностью, которые всегда ссылаются на один объект.

Указатели UPL не являются заменой умных указателей стандартной библиотеки C++ и могут использоваться совместно с ними (конечно, одновременно объект может находиться под управлением только одной библиотеки). UPL предназначена для случаев, когда не хватает функциональности умных указателей стандартной библиотеки C++ и требуются дополнительные возможности для организации связей между объектами в многопоточной среде.

Например, с этими двумя пунктами у меня возникли затруднения при решении с помощью стандартных указателей:

• Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.
  
• Указатель upl::unified позволяет передать уникальное владение объектом в цепочке, где может выполняться копирование.

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

Здравствуйте, Alexander G, Вы писали:
VT>> Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.
AG>Как это сделано? все указатели сделаны поверх типичной реализации shared, даже unique?

Да, реализация типичная — на счётчиках ссылок. Более того, сейчас она довольно наивная, чтобы не впадать в преждевременную оптимизацию. upl::unique тоже ссылается на контрольный блок со счётчиками, так что он тяжелее, чем std::unique_ptr. Хорошо было бы сделать реализацию на чём-то готовом, например std::shared_ptr, но у меня не получилось, поэтому пришлось изобретать велосипед.

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

Здравствуйте, ViTech, Вы писали:

NB>>какие проблемы решались при создании библиотеки, которые не могут решить стандартные указатели?

VT>Например, с этими двумя пунктами у меня возникли затруднения при решении с помощью стандартных указателей:
VT>

Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.

что с таким указателем можно делать кроме как проверить жив ли объект или нет?

VT>

Указатель upl::unified позволяет передать уникальное владение объектом в цепочке, где может выполняться копирование.

что при этом происходит с остальными шаредами?

Здравствуйте, night beast, Вы писали:

VT>>Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.
NB>что с таким указателем можно делать кроме как проверить жив ли объект или нет?

Можно:

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

Пример использования.

VT>>Указатель upl::unified позволяет передать уникальное владение объектом в цепочке, где может выполняться копирование.
NB>что при этом происходит с остальными шаредами?

Уникальное владение из upl::unique нужно перемещать в upl::unified, который по пути может и копироваться. При попытке передать владение в upl::unique из другого указателя, будет выброшено исключение, если объект уже находится в чьём-то владении. Пример TransferUnique.

Здравствуйте, ViTech, Вы писали:

VT>>>Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.
NB>>что с таким указателем можно делать кроме как проверить жив ли объект или нет?

VT>Можно:
VT>

VT>С помощью upl::unified можно временно продлить время жизни объекта в заданной области видимости, что позволяет корректно завершить работу с ним, даже когда все остальные указатели на этот объект удалены.

при попытке использовать викптр объект из основного перемещается и по завершении обратно не возвращается?
какие реальные задачи решает такой странный юзкейс?

VT>>>Указатель upl::unified позволяет передать уникальное владение объектом в цепочке, где может выполняться копирование.
NB>>что при этом происходит с остальными шаредами?

VT>Уникальное владение из upl::unique нужно перемещать в upl::unified, который по пути может и копироваться. При попытке передать владение в upl::unique из другого указателя, будет выброшено исключение, если объект уже находится в чьём-то владении. Пример TransferUnique.

хз. имхо это все совершенно бесполезная фигня, создающая проблемы на ровном месте.

Здравствуйте, ViTech, Вы писали:

VT>Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.

Какая-то шиза в чистом виде. unique_ptr предназначен для ситуаций, когда должен быть только один указатель на объект. И владение unique_ptr-ом определяет время жизни объекта, на который ссылаются. Причем, с точки зрения эффективности реализации (очень важной, поскольку мы в C++) ключевой момент в том, что unique_ptr не использует никакой формы подсчета ссылок (т.е. нет скрытых накладных расходов).

Если это не так, т.е. по условиям задачи вам нужна сильная ссылка на объект (для определения времени его жизни) и, в то же время, слабые ссылки, то вам нужен не unique_ptr, а как раз таки shared_ptr.

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

Здравствуйте, night beast, Вы писали:

NB>при попытке использовать викптр объект из основного перемещается и по завершении обратно не возвращается?
NB>какие реальные задачи решает такой странный юзкейс?

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

NB>хз. имхо это все совершенно бесполезная фигня, создающая проблемы на ровном месте.

Для вас фигня, а для меня нет. Кому-то и raw pointers хватает .

Здравствуйте, ViTech, Вы писали:

VT>[] Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.

Что то у меня порвался шаблон немного
1. "upl::unique" — явно предполагает "уникальность" владения хранимым по указателю объектом
2. upl::weak over upl::unique — уничтожает эту самую уникальность, так как указываемый объект теперь доступен более чем из одного указателя

получилась не уникальная уникальность?

Здравствуйте, kov_serg, Вы писали:

_>Ждём Unified Math Library, Unified GUI Libaray и Unified Coroutine and Threading Library.

А так же Unified Qt Library, Unified STL Library и Unified Boost Library.

Здравствуйте, so5team, Вы писали:

VT>>Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.

S>Какая-то шиза в чистом виде. unique_ptr предназначен для ситуаций, когда должен быть только один указатель на объект. И владение unique_ptr-ом определяет время жизни объекта, на который ссылаются. Причем, с точки зрения эффективности реализации (очень важной, поскольку мы в C++) ключевой момент в том, что unique_ptr не использует никакой формы подсчета ссылок (т.е. нет скрытых накладных расходов).

Если вам нужен такой вариант использования, std::unique_ptr для этого и есть. Если смотреть с точки зрения ассоциативных связей UML, то уникальность — это свойство ассоциативной связи в объекте-владельце, а не объекта, на который ссылаются.

S>Если это не так, т.е. по условиям задачи вам нужна сильная ссылка на объект (для определения времени его жизни) и, в то же время, слабые ссылки, то вам нужен не unique_ptr, а как раз таки shared_ptr.

S>Зачем может потребоваться unique, который не unique, а суть shared, понять из ваших наукообразных определений решительно не удается.

Эти "наукообразные определения" особо-то и не мои, они в UML описаны. Если вам не понятен раздел Ассоциативные связи, значит вам эта библиотека не нужна.

Здравствуйте, ViTech, Вы писали:

NB>>при попытке использовать викптр объект из основного перемещается и по завершении обратно не возвращается?
NB>>какие реальные задачи решает такой странный юзкейс?

VT>Юзкейс внезапной смерти объекта, находящегося в уникальном владении, при наличии слабых ссылок на него.

нет. какой юз кейс слабых ссылок, которые забирают владение?

Здравствуйте, ViTech, Вы писали:

VT>Если вам нужен такой вариант использования, std::unique_ptr для этого и есть. Если смотреть с точки зрения ассоциативных связей UML, то уникальность — это свойство ассоциативной связи в объекте-владельце, а не объекта, на который ссылаются.

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

S>>Зачем может потребоваться unique, который не unique, а суть shared, понять из ваших наукообразных определений решительно не удается.

VT>Эти "наукообразные определения" особо-то и не мои, они в UML описаны.

Скорее всего есть огромная разница между:

• тем, что описано в UML;
  
• тем, что восприняли вы;
  
• тем, как вы свое восприятие "положили" на возможности C++.

VT>Если вам не понятен раздел Ассоциативные связи, значит вам эта библиотека не нужна.

Синдром непризнанного гения?

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

Здравствуйте, night beast, Вы писали:

NB>нет. какой юз кейс слабых ссылок, которые забирают владение?

Они не забирают владение. Они позволяют предоставлять доступ к объекту в функции/методе, и поддержать жизнь объекта на это время, с учётом того, что в другом потоке, в это же время, исходный upl::unique может удалиться. Если же попытаться из weak получить unified и затем unique, то должно выбрасываться исключение, если на объект есть другая строгая ссылка.

Здравствуйте, vopl, Вы писали:

V>Здравствуйте, ViTech, Вы писали:

VT>>[] Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.

V>Что то у меня порвался шаблон немного
V>1. "upl::unique" — явно предполагает "уникальность" владения хранимым по указателю объектом
V>2. upl::weak over upl::unique — уничтожает эту самую уникальность, так как указываемый объект теперь доступен более чем из одного указателя

V>получилась не уникальная уникальность?

Если объект находится под управлением std::unique_ptr, то больше никто и никогда не может обращаться к этому объекту (кроме владельца)? Я рассматриваю владение с точки зрения ассоциативных связей UML, где weak для unique — это противоположный полюс ассоциации. С такого угла зрения есть какое-либо противоречие?

Здравствуйте, ViTech, Вы писали:

NB>>нет. какой юз кейс слабых ссылок, которые забирают владение?

VT>Они не забирают владение. Они позволяют предоставлять доступ к объекту в функции/методе, и поддержать жизнь объекта на это время, с учётом того, что в другом потоке, в это же время, исходный upl::unique может удалиться. Если же попытаться из weak получить unified и затем unique, то должно выбрасываться исключение, если на объект есть другая строгая ссылка.

то есть на время предоставления доступа к объекту в функции/методе существует два уника (уник со счетчиком ссылок = 2)?

Здравствуйте, night beast, Вы писали:

VT>>Они не забирают владение. Они позволяют предоставлять доступ к объекту в функции/методе, и поддержать жизнь объекта на это время, с учётом того, что в другом потоке, в это же время, исходный upl::unique может удалиться. Если же попытаться из weak получить unified и затем unique, то должно выбрасываться исключение, если на объект есть другая строгая ссылка.

NB>то есть на время предоставления доступа к объекту в функции/методе существует два уника (уник со счетчиком ссылок = 2)?

Нужно разделять понятия "владение" и "доступ". К объекту, находящемуся в уникальном владении, другие объекты могут получать доступ? Я считаю, что да, могут. Но они не могут просто так получить владение им. Так что в функции/методе владелец будет один, а доступ через unified получить можно много раз, и держать его (доступ), в случае необходимости. В текущей реализации для строгого владения (unique, shared) и для доступа (unified) используются разные счётчики.

Здравствуйте, so5team, Вы писали:

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

Эта штука, в первую очередь, нужна мне. Мне она нужна в условиях работы в многопоточной среде для организации ассоциативных связей между объектами. В частности, для нормальной поддержки уникального владения (композитной агрегации), чтобы соблюдалась целостность связей. Если взять пример TransferUnique, то я хочу, чтобы Car уникально владел Engine. И чтобы можно было передать владение Engine или из фабрики, или сняв с другого Car, через очередь сообщений/команд. std::unique_ptr в std::function<void()> не лезет. Можно сырые указатели пересылать, но мне это не нравится.

Здравствуйте, ViTech, Вы писали:

VT>>>[] Указатель upl::weak может ссылаться на объект, который находится под управлением upl::unique.

V>>Что то у меня порвался шаблон немного
V>>1. "upl::unique" — явно предполагает "уникальность" владения хранимым по указателю объектом
V>>2. upl::weak over upl::unique — уничтожает эту самую уникальность, так как указываемый объект теперь доступен более чем из одного указателя

V>>получилась не уникальная уникальность?

VT>Если объект находится под управлением std::unique_ptr, то больше никто и никогда не может обращаться к этому объекту (кроме владельца)? Я рассматриваю владение с точки зрения ассоциативных связей UML, где weak для unique — это противоположный полюс ассоциации. С такого угла зрения есть какое-либо противоречие?

С такого — противоречий нет. Оригинальный вопрос был не про противоположный полюс.

class Car;
class Engine;

class Car
{
    upl::unique<Engine> engineStrong;   //рассматриваем этот unique как полюс ассоциации "машина [0,1] -- [0,1] двигатель"
    upl::weak<Engine>   engineWeak;     //альтернативный полюс для engineStrong. Вот про него речь. С ним проблемы.
};

class Engine
{
    unspecified<Car> car;               //противоположный для engineStrong+engineWeak, может быть upl::weak, а может что то другое. Не интересует
};