Согласен).

Необходимо, прежде всего, определиться, что есть Light и какие отношения между Light и его Light::masterLight.

• Является ли экземпляр master_light частью экземпляра light (должен ли быть удален master_light при удалении light)?
• Является ли экземпляр master_light уникальным по отношению к light (может ли один и тот же master_light относится к нескольким light)?
• Сколько различных master_light может относится к light (0, 1, 5, 10, много)?
• Не существует ли глобального менеджера ресурсов, управляющего всеми экземплярами light?
• Не определяется ли время жизни экземпляра light лишь областью видимости глобальных/локальных переменных?
• Предполагается ли конкурентный доступ к одному экземпляру light?
• Предполагается ли параллельный доступ к разным экземплярам light?

Ответы на эти вопросы позволят сформировать модель отношений и выбрать способ реализации.

ИМХО, без модели даже проект не начну. Это как без чертежей и технологии сборки пытаться создать сложную конструкцию или механизм.
Вместо слаженного продукта получается набор костылей. Хотя бы набросок модели должен быть.


Существует большое количество умных указателей, каждый из которых обладает определенными особенностями - полезными свойствами и накладными расходами.
Зная эти характеристики можно подобрать нужный тип указателя исходя их особенностей решаемой задачи.
Используемый инструмент-библиотека, ИМХО, должен обеспечивать легкий способ изменения этих характеристик в случае, если особенности задачи меняются.

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


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

А я его и не начинал Это старый (но работающий) код который нужно улучшить. Попробуем прямолинейно. Все проблемы возникают из-за того что неизвестно кто ссылается на мастера, их всякий раз нужно искать "по всему списку объектов" - коряво. Так добавим нужные данные и методы, это выглядит примерно так

C++ (Qt)
struct Light {
..
private:
  Light * m_master;
  QVector<Light *> m_slaves;
..
public:
  void Link2Master( Light * master );
  void UnlinkFromMaster( void );
  bool HasGrandMaster( const Light * master ) const; // пресечь циклическую зависимость
};
 

Реализация очевидна. Ну и в деструкторе нужно подсуетиться. И в копировании (m_slaves копироваться не должен). По-моему общность здесь бросается в глаза. Тем более что с пяток таких мест я помню навскидку (masterMaterial и.т.п)

Ага, "ну вот и делай свой велик"  Но скажите, почему я со стандартных средств ровным счетом ничего не имею? Разве велики - это так уж хорошо/правильно? Неужели у меня какая-то причудливая, редкая задача? Да нет же, самая рядовая/типовая. И какой тогда смысл в "умных" указателях если ума у них - шо у курчонка, а толку с гулькин "нос"?

Заменил реализацию указателей UPL на обёртки над указателями std. Теперь upl::unique/shared/unified - это обёртки над std::shared_ptr, а upl::weak - обёртка над std::weak_ptr. При этом несколько уменьшился диапазон возможностей указателей, но появилась более тесная интеграция с указателями std. upl::unique можно создавать из std::unique_ptr,  upl::shared/unified из std::shared_ptr, upl::weak из std::weak_ptr. В обратную сторону работает только получение std::shared_ptr из upl::shared.  Так что если уникальное владение делать через std::shared_ptr, то, при замене его на upl::unique, накладные расходы в run-time останутся такими же. Может несколько увеличиться время компиляции (не проверял ещё), но это может компенсироваться более понятными ошибками компиляции, которые я добавил для указателей upl. Также стоит обратить внимание на более удобный и унифицированный доступ к значению указателя через upl::access().

В качестве примера можно рассмотреть взаимодействие объектов трёх типов: Car, Engine и Monitor. Car уникально владеет одним Engine, несколько Monitor могут наблюдать за одним Engine, Car и Monitor независимы друг от друга (UML диаграмма классов в рисунке вложения). Эмулируется работа объектов в разных потоках. Составляется очередь команд, которая тоже выполняется в отдельном потоке. Основной код примера:

C++ (Qt)
class Printable
{
public:
    virtual ~Printable() {}
    virtual void print() const = 0;
};
 
template <class P>
std::enable_if_t<upl::Pointer<P, const Printable>>
print(const P& pointer)
{
#if 1
    // Access to the 'pointer' by the lambda.
    upl::access(pointer,
                [](auto& value) { value.print(); },
                [] { std::cout << "no value" << std::endl; });
#else
    // Similar access to the 'pointer' by the "standard" way.
    const auto& pointer_accessor = upl::access(pointer);
    if (pointer_accessor)
    {
        auto& value = *pointer_accessor;
        value.print();
    }
    else
    {
        std::cout << "no value" << std::endl;
    }
#endif
}
 
class Engine : public Printable
{
public:
    Engine() {}
    Engine(const std::string& model) : m_model{model} {}
    ...
    std::string model() const { return m_model; }
    int  currentRpm() const   { return m_current_rpm; }
 
    void accelerate() { m_current_rpm++; }
    ...
private:
    std::string m_model;
    int m_current_rpm{0};
};
 
class Car : public Printable
{
public:
    using SingleEngine = upl::unique_single<Engine>;
 
    Car(const std::string& brand, SingleEngine engine)
        : m_brand{brand}, m_engine{std::move(engine)}
    {}
 
    SingleEngine replaceEngine(SingleEngine engine)
    {
        m_engine.swap(engine);
        return engine;
    }
 
    void drive() { (*m_engine).accelerate(); }
 
    std::string brand() const { return m_brand; }
    ...
private:
    std::string  m_brand;
    SingleEngine m_engine;
};
 
class Monitor : public Printable
{
public:
    using WeakEngine = upl::weak<const Engine>;
 
    Monitor() {}
    Monitor(const std::string& model, const WeakEngine& engine)
        : m_model{model}, m_engine{engine}
    {}
 
    std::string model() const { return m_model; }
 
    void setEngine(const WeakEngine& engine)
    { m_engine = engine; }
    ...
private:
    std::string m_model;
    WeakEngine  m_engine;
};
 
void driveCar(upl::weak<Car> car)
{
    using namespace std::chrono_literals;
 
    for (int i = 0; i < 20; ++i)
    {
        std::this_thread::sleep_for(40ms);
        upl::access(car, [](auto& car) { car.drive(); });
    }
}
 
void monitorEngine(upl::weak<const Monitor> monitor)
{
    using namespace std::chrono_literals;
 
    for (int i = 0; i < 10; ++i)
    {
        std::this_thread::sleep_for(100ms);
        upl::access(monitor, [](auto& monitor) { monitor.print(); });
    }
}
...
int main()
{
    // With the 'upl::itself' parameter, the 'upl::unique' creates the 'Engine'
    // in the same way as the 'std::make_unique<Engine>'.
    upl::unique<Engine> vaz_i4{upl::itself, "VAZ I4"};
    upl::unique<Engine> zmz_i4{upl::itself, "ZMZ I4"};
 
    upl::shared<Monitor> monitor_1{upl::itself, "ME 1", vaz_i4};
    upl::unique<Monitor> monitor_2{upl::itself, "ME 2", zmz_i4};
 
    upl::shared<Car> lada{upl::itself, "LADA", std::move(vaz_i4)};
    upl::unique<Car> uaz{upl::itself, "UAZ", std::move(zmz_i4)};
 
    std::vector<std::thread> threads;
    // Drive cars in separate threads.
    addThread(threads, [&] { driveCar(lada); });
    addThread(threads, [&] { driveCar(uaz); });
    // Monitor engines in separate threads.
    addThread(threads, [&] { monitorEngine(monitor_1); });
    addThread(threads, [&] { monitorEngine(monitor_2); });
 
    using EngineStore = upl::shared<std::vector<Car::SingleEngine>>;
    EngineStore engine_store{upl::itself};
    (*engine_store).emplace_back(upl::itself, "VAZ V4 Turbo");
 
    std::queue<std::function<void()>> commands;
 
    commands.emplace([ = ] // Capture the shared 'engine_store' and the 'lada' by value.
    {
        auto& store = (*engine_store);
        auto engine = (*lada).replaceEngine(std::move(store.back()));
        store.pop_back();
        store.push_back(std::move(engine));
    });
 
    commands.emplace( // Move the unique 'uaz' into the command with the 'upl::unique_carrier' helper.
        [uaz = upl::unique_carrier{std::move(uaz)}]() mutable
        { auto wall = std::move(uaz); });
 
    commands.emplace( // Capture the unique 'monitor_2' by the upl::weak.
        [ =, m = upl::weak<Monitor>{monitor_2}]
        { upl::access(m, [&](auto& m) { m.setEngine((*engine_store)[0]); }); });
 
    // Execute commands in a separate thread.
    addThread(threads, [&] { execute(std::move(commands)); });
 
    for (auto& thread:threads)
        thread.join();
 
    print(lada);
    print(uaz);
 
    return 0;
}

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

В качестве более "продвинутого" использования UPL (в частности концептов), можете посмотреть на тесты. Например, в одном этом методе выполняется создание указателей с объектами разного типа, разным типом владения, разной кратностью и разной реализацией указателей. А здесь вызываются функции для проверки указателей по заданным правилам, согласно типу владения и реализации.