Добрый день

Задача только что возникла, тщательно не обдумывал, так что может и все просто. Псевдокод

C++ (Qt)
struct MyClass {
...
 const CDrawList & GetDrawList( const CPolygonList * poly )
 {
   CDrawList & list = m_hash[poly];
   if (list.IsEmpty())
     poly->BuildDrawList(list, ...);
   return list;
 }
...
};
 

Т.е. обычный кеш. Проблема в том что ключ (указатель на CPolygonList) могут застрелить из очень разных мест. Как автоматом вычищать его из MyClass ?

Да, и давно хотел сказать: всякий раз когда речь идет о вумных указателях почему-то никто не упоминает что в достаточно большом написанном коде "заменить голый на вумный" может быть очень и очень непросто. Напр в данном случае CPolygonList не может быть вумным - слишком много кода завязано не него, последствия непредсказуемы. А вот добавлять в него вумные члены - пожалуйста

Спасибо

Тогда как в том анекдоте "наблюдение за наблюдающим" - ведь MyClass тоже могут грохнуть.

Ну и решение "без ограничений" тоже интересно. Хорошо, вот CPolygonList мог быть шаред - и что с того? Ключом его все равно не сделать.

Ну не все так печально как в моем любимом антипаттерне lava flow Почему "сопровождаем"? Разрабатываем, добавляем новые фичи, приведенный псевдокод - одна из них. Давление старого кода конечно есть, но это нормально, "с нуля" хорошо плагины писать (иногда).

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

CDrawList - это структура для подачи индексов в glDrawElements/glMultiDrawElements.
CPolygonList - ну ясно контейнер фейсов.

Но сам CPolygonList обычно не может сформировать CDrawList - фейсы могут быть сгруппированы "по материалам" - которыми и управляет MyClass, возможно имя типа CMaterialSet было уместнее. Понятно изменились/удалились фейсы (CPolygonList) - кешированный CDrawList нужно сбросить.   

Вот и ВСЕ. Более того, здесь не нужны даже эти (зачаточные) познания. Ясно просматривается "кеширование". Ясно что MyClass использует указатель(и) на др класс, это естественно, не один же класс все-все делает. Встает законный вопрос как обеспечить надежность/достоверность используемых указателей. Чего ото "темплейтить" клопа с "совместным владением", "временем жизни" и.т.п.? Я ни о чем таком не спрашивал Впрочем если думать лень - повод всегда найдется

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

Если Вы говорите, что "что ключ (указатель на CPolygonList) могут застрелить из очень разных мест", то что может произойти здесь, если его таки застрелят?

В аргументе poly может быть nullptr? Или это тоже слишком глубокий анализ?


В определённых ситуациях (эл-тов хеша будет мало и т.п.) хранить идентификатор и weak_ptr считаю нормальным решением, почему бы и нет. Другие решения могут быть сложнее.

Про архитектуру всего проекта никто и не говорил, достаточно знаний про MyClass, CPolygonList  и связанными с ними сущностей в контексте текущей задачи.

Например, такой вариант:

C++ (Qt)
const CDrawList & GetDrawList( const std::weak_ptr<const CPolygonList>& poly_carrier )
{
    std::shared_ptr<const CPolygonList> poly_lifetime_locker = poly_carrier.lock();
    if (!poly_lifetime_locker)
        return ???;
 
    const CPolygonList& poly_object = *poly_lifetime_locker;
    CDrawList & list = m_hash[poly_object.id()];
    if (list.IsEmpty())
        poly_object.BuildDrawList(list, ...);
    return list;
}

Как можно заметить, сущностей, связанных с poly, несколько больше, чем может показаться на первый взгляд (из первого сообщения). Их может быть ещё больше, например, poly_access_locker для синхронизации доступа к объекту. Типы этих сущностей зависят от того, что с ними будет делать метод класса, какие связи устанавливать между объектами и т.п. Можно всё это множество сущностей попробовать описывать только типом голого указателя, но мне что-то не хочется.


Вы бы тогда может и нет, а другие вполне да .


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


Я не знаю, почему Вы не видите . Одно уже было:
С отсылкой на вариант с обратной связью из SharedHash/Set.

Нет, это настойчивое стремление втулить совсем другое: анализ происходящего. В частности, что переменные одного типа (CPolygonList *) могут играть разные роли, а не одну, как это может показаться на первый взгляд. В m_hash нужен идентификатор объекта, а не указатель на него. Это так совпало (как это часто и бывает с типами голых указателей), что указатель (адрес в памяти) можно считать идентификатором. Вариант возможный, но не единственный и не самый надёжный. Далее, нужно определить, что объект с таким идентификатором существует. Сделать это можно с помощью weak_ptr и бонусом получить доступ к объекту и продление его жизни (если требуется), можно другими способами с другими бонусами/недостатками (например, Smart observers to use with unique_ptr). В итоге может получиться, что в GetDrawList() достаточно передать идентификатор объекта (poly), а не указатель/ссылку на него. И я не говорю, что нужно везде пихать умные указатели, а наоборот, делать это по необходимости. Чем меньше шелухи - тем лучше.


Зачистку хеша в SharedHash/Set разве недостаточно обсудили? Основных вариантов вижу два: либо строить систему которая много знает о связях между объектами и пытается их вовремя разрывать, либо работать в условиях возможного существования "висячих" концов связей. Или комбинированный подход: по возможности (когда это не очень сложно, нет циклических зависимостей и т.п.) удалять связи, иначе работать с висячими концами. Выбор варианта зависит от текущей ситуации и в будущем может измениться. Писать код надо так, чтобы изменения деталей реализации не беспокоили остальные части проекта. Что возвращает нас к анализу сущностей и связей между ними .

Ну я себе такой велик сделал и теперь очень доволен . Чего и Вам желаю.