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

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

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

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

Отвечу на возникающие вопросы. Аргументированная критика приветствуется .

Лучше в случаях работы в многопоточной среде. В частности, можно создать слабую ссылку/связь upl::weak на объект, находящийся под уникальным владением upl::unique. Далее, через upl::weak можно безопасно получить доступ к объекту. Тут возможны два варианта:
1. Объект удалился. upl::weak::expired() == true, объекта нет, обращаться не к чему.
2. На момент доступа через upl::weak объект существует, но внезапно может удалиться в другом потоке. upl::weak::lock() продлевает время жизни объекта до конца работы текущей области видимости.

Если коротко, то добавлена связка upl::unique <-> upl::weak, аналогичная std::shared_ptr <-> std::weak_ptr, только для уникального владения. Если подробнее, то в библиотеке набор указателей, каким я бы хотел его видеть. С нормальным уникальным владением, с унифицированным доступом, с различной кратностью, с поддержкой концептов в шаблонах и прочим.

Это от реализации зависит . Кстати, можно написать свою, под свои нужды. Текущая реализация наивная, и ещё до конца не доделанная, ибо не хочется велосипед изобретать. Она нужна для проверки концепции. Сейчас делаю реализацию с более узким спектром возможностей, но на готовых std::shared_ptr/std::weak_ptr. В ней производительность будет такой же, как у std::shared_ptr.

В идеале хотелось бы получить интеграцию с указателями std, чтобы, во-первых, изобретать велосипеды по минимуму, во-вторых была возможность взаимодействовать с кодом, ориентированным на std. Но получается так, что даже если сделать реализацию UPL на основе std::shared_ptr/weak_ptr, то совместимы будут только std::shared_ptr и upl::shared (возможно их взаимное преобразование друг в друга). std::unique_ptr и std::weak_ptr можно только в одну сторону перевести - в upl::unique, upl::weak, обратно не получится (хотя в случае upl::unique -> std::unique_ptr есть варианты, но довольно зыбкие). Так что, в зависимости от реализации UPL, это может быть частичная интеграция с указателями std, а может быть их альтернатива.


Для уникального владения можно взять и использовать std::shared_ptr (я так понял, что многие так и делают). Но моё личное мнение такое, что это то же самое, как предложить не пользоваться ключевыми словами const, explicit, protected, private, delete и т п. Писать программы станет проще, не будет надоедливых ошибок компилятора, можно меньше ломать голову const-или-не-const. Станет ли программа от этого лучше? Сомневаюсь. Ещё такой момент: типов ассоциативных связей всего три. Три, Карл!!! И тут говорят: выкидывайте из модели все композиции, потому что на великом и могучем С++ нормальное(потокобезопасное) уникальное владение сделать нельзя/трудно/не охота/а зачем, и мы это на std::shared_ptr будем делать. Для меня это нездоровая ситуация.


Программисты разные бывают, кто не хочет соблюдать const correctness, тот и о типе владения не будет особо задумываться, влепит std::shared_ptr  и всё. Выбор подходящих указателей нужен тем, кто хочет иметь полный набор возможностей, кто пишет классы по модели UML, и хочет защитить их от неправильного использования. Например, как с помощью explicit защищают от случайного преобразования типов.


Если в программе получается организовать связи между объектами и доступ к ним с помощью std::unique_ptr и raw pointers, и исключены появления dangling pointers, то так и следует делать. Но в более-менее сложной программе не факт, что получится соблюдать целостность связей проще и эффективнее, чем подсчётом ссылок. upl::unique не является заменой std::unique_ptr, у них одинаковая семантика владения, но немного разное поведение при уничтожении объекта. UPL ориентирована на многопоточное использование, где объекты могут внезапно умирать.


Ситуация с реализациями такая: задумка UPL в том, чтобы сделать работу с указателями более упорядоченной и систематизированной. Можно провести аналогию со стандартными контейнерами. Есть концепты контейнеров, есть стандартные алгоритмы для работы с ними, и есть конкретные реализации контейнеров. В UPL я попытался определить типы владений и составить набор концептов указателей. Эти концепты можно использовать в обобщённых алгоритмах, чтобы не было привязок к каким-то конкретным типам указателей (std::shared_ptr, upl::shared). Соответственно, реализаций указателей может быть несколько, равно как можно написать свою версию std::vector, например. Будет ли кто писать свои реализации? Маловероятно ). Но такая возможность есть. В самой же UPL будет какая-то реализация, которая подойдёт для подавляющего большинства случаев. Скорей всего это будет реализация на основе std::shared_ptr/weak_ptr.


Тег std::in_place используется для "пробы пера": насколько удобно пользоваться такой формой создания/инициализации объекта, в отличие от new SomeObject(), make_unique<SomeObject>(),  make_shared<SomeObject>(). Обозначает: создание объекта в этом месте (программы, а не стек/куча) средствами самого класса. Для объекта на стеке свои правила времени жизни, там ссылок достаточно, вряд ли надо делать указатели настолько универсальными.


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

Здесь та самая проблема:

Когда были только "голые" указатели, то выбора не было и думать особо не надо было. О владении вспоминали только когда память текла, и решали, кто таки должен удалять объект. И как это обозначить. При этом, под тот код можно было построить UML модель, хоть разработчик классов об этом и не подозревал . С появлением умных указателей в С++11 уже появился выбор. Хотя, похоже, он сводился к shared_ptr или не shared_ptr?

С древним кодом сложно. Сначала надо выявлять, кто владелец, а кто просто посмотреть зашёл. Затем, по-хорошему, тип владения (а по-простому - std::shared_ptr). Если есть вероятность появления "висячих" указателей, и необходимо иметь возможность проверить валидность указателя, то без накладных расходов тут вряд ли обойдётся. В этом отношении std::unique_ptr вряд ли что-то адекватное может предложить. При использовании умных указателей изменится способ доступа к объектам. В частности для std::weak_ptr надо lock() делать. Так что работы много, и не факт, что всё хорошо закончится.


В этом случае стандарт С++ может предложить std::observer_ptr. Но года через 2, в С++20 . Хотя, похоже, это простейшая обёртка над raw pointer и проверить "живучесть" объекта через него вряд ли получится. Можно написать свой.

Ещё ведутся работы над Profiles с Bounds safety и Lifetime safety, наверное что-то похожее на то, что в Rust есть. Но когда это будет нормально сделано (и будет ли сделано вообще) - не известно.

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

В сухом остатке скорей всего происходит то, что выделено жирным . Никто же не поругает за то, что композицию из модели UML реализовали через shared_ptr. Если вообще кто-то задумается о какой-то там модели. Кто-то может задумается, но успокоит себя мыслью: "на самом деле там же совместное владение, в методе/функции происходит же захват владения, зачем тогда уникальным прикидываться?". Кто-то попробует использовать unique_ptr, споткнётся пару раз, плюнет, и перейдёт на shared_ptr.

С уникальным владением сложнее обращаться, потому что оно накладывает ограничения. Например я столкнулся с таким: хочется создать очередь команд из std::queue<std::function<void()>>, но нельзя сделать std::function<void()> = std::bind(&SomeObject::someMethod, object, std::move(unique_arg));, потому что std::function - CopyConstructible (пример TransferUnique). Приходится какой-то костыль лепить.

Ещё пример. Есть Guidelines Support Library , в ней делают not_null (Restricts a pointer or smart pointer to only hold non-null values). Но этот not_null не работает с unique_ptr, уже почти 3 года прошло . И всем пофиг (почти).

Далее. Igors затронул интересную тему. С голыми указателями писать программу проще, не надо задумываться о типах владения и прочем (потом может боком вылезти, но кто об этом задумывается). В параметрах методов/функций тоже всё проще: обычно какой-нибудь SomeObject *. Если же делать по уму и использовать разные типы владения, то в параметрах будет больше разнообразия: unique_ptr, shared_ptr, weak_ptr (и SomeObject * тоже могут присутствовать). С таким многообразием параметров очень скоро программу писать станет не интересно, и везде останутся одни лишь shared_ptr. Я подозреваю, что сейчас так и происходит.

Где-то может использоваться внутреннее управление временем жизни объектов, и другое уже не прилепишь. Тот же QObject.

Из таких предпосылок я делаю вывод, что просто никто не хочет связываться с уникальным владением, раз можно обойтись совместным и никто за это не осудит. Ну а "модель UML", "типы владения" и пр. - это просто слова, которые важны каким-нибудь перфекционистам. Мне например ). А так как есть shared_ptr и его в общем-то хватает, то зачем ещё какие-то библиотеки таскать, тем более от какого-то неизвестного ViTech ). Вот если б Herb Sutter такое предложил, то да )).


Нечто большее может как раз лежать в области унифицированного доступа к объектам. Грубо говоря, вместо зоопарка uniqe, shared, weak в параметрах, можно использовать один upl::unified. Потому что вся эта шелуха с указателями/ссылками возникает из-за ограниченности языков программирования/аппаратных платформ, а на деле нужны сами объекты. Чтобы очистить объект от этой шелухи и добраться до него приходится много неинтересного кода писать. Вот сущности типа upl::unified и концепты (пример) могут в этом помочь. Тогда и уникальное владение может будет проще использовать и оно получит распространение.


В UML про указатели не говорят, зато много говорят о токенах объектов. Если коротко, то токены и указатели по сути одно и то же (умные указатели, а не голые с арифметикой). Я бы даже сказал так: токен - это урезанный указатель. По крайней мере с технической точки зрения (реализации ) у меня так получается. И все сущности более высокого уровня (свойства, параметры, переменные) строятся на основе токенов. И доступ к объекту через токен, скорей всего, будет выглядеть как *token. Тут мог бы помочь operator dot, но я что-то не вижу подвижек по нему, такое ощущение, что он заглох.

Так что UPL про указатели для тех, кто привык к семантике умных указателей и не нужно ничего лишнего. На указателях тоже можно следовать моделям UML, просто это будет не так явно выглядеть. Получилось так, что эту часть можно выделить из более крупного проекта. Почему бы и нет.

Тем же, кому нужны более высокоуровневые сущности: свойства, параметры, переменные, которые являются коллекциями по трактовке UML, предлагается другая библиотека, со всеми этими наворотами. В основе которой я вижу токены, коллекции, и Ranges. Если появятся желающие это обсудить - я будут только рад .

Мы с ViTech, как всегда, перешли в приват))).


Это с какой стороны посмотреть)). Имхо, прописной истины как таковой нет, зато куча ЕСЛИ.

С точки зрения программы на C++ здесь все нормально.

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

С точки зрения поддержки, фиксов и т.п. Нужно применить некоторые усилия, чтобы понять что есть что. Указатель сам по себе ничего не говорит о том, чем является и какими свойствами должен обладать.
Что это Light * ? - значение, динамический массив, агрегация, композиция, какая предполагается мультипликативность и т.д. и т.п. Какие свойства присущи Light * masterLight ?
Чтобы выяснить это, требуется проанализировать сам код, а при поиске ошибок еще и найти места некорректного использования.

В этом могла бы помочь объектно-ориентированная модель, как абстракция более высокого уровня. Но для этого её нужно проектировать)). Или ... реализовать конструкции, которые явно отражают понятия модели в программе.
Сразу качественный скачок от кодирования к моделированию сложен (как от 2D перейти к 3D, или от 3D к 4D), поэтому UPL предлагает ряд более простых инструментов в виде дополнительных умных указателей.

Здесь я схитрю)), этот код не на UPL.

C++ (Qt)
struct Light {
  ...
    using WeakMaster = AssociationEnd< Light, AggregationKind::None >;
    WeakMaster masterLight;  // полюс вида None ассоциативной связи агрегации c мастером
 
// пример использования мастера
    float GetIntesity( void ) const 
    {
        // гарант доступа к мастеру на протяжении всего вызова метода
        AccessGuard<WeakMaster > master_access_guard = masterLight;
        if ( master_access_guard && this->inheritIntensity())    // возвращаем значение мастера 
            return master_access_guard->GetIntensity();
        else 
            return this->m_intensity;  // или собственное
    }
};
 

Из кода явно видно, что есть что. А наличие гаранта в методе позволяет обеспечить при необходимости "продление жизни" masterLight и/или однопоточный доступ к masterLight и/или ...

Ну особой радости она не доставляет. Простой случай - удаление мастера. Надо пробежаться по всем объектам типа Light и обнулить удаляемого мастера. Но перед этим надо ж сохранить undo - значит еще пробежаться. 

Аналитик/эксперт спросит: a cколько может быть объектов типа Light?  Ну сотни (тысяч пока не было). Значит и проблемы нет, проще = лучше. Не все так просто. Операция сама по себе приемлема по времени, но может попасть в другую с хорошей кратностью. Напр юзер уже не раз просил рисовать мастеров с др иконкой - и тут уже хз так ли безобидны такие пробежки. В общем, данные слишком примитивны, требуется много/больше кода чтобы эту простоту поддерживать.

Обойтись стандартными вумными указателями я могу хотя бы так

C++ (Qt)
struct Light {
 ...
 QSharedPointer<Light> mSharedPtr;  // приватный шаред на себя, создается в конструкторе с пустым Deleter
 ...
 QWeakPointer<Light> GetWeakPtr( void );
};

Думаю что лепить такую городушку не стоит - слишком мал "выйгрышь". Да, теперь можно "не вычеркивать", но на undo все равно прописывать придется. Лучше смотрится простая организация (напоминает парент-чайлд), т.е.

- на объект можно ссылаться, он знает ссылающихся (напр хранит контейнер указателей)
- и наоборот,  объект хранит контейнер тех на которых он сам ссылается

В общем виде это кусок пожирнее чем просто "валиден"(указатель) и "продлить жизнь" (что кстати спорно). Но как к нему подступиться?