2 мапы и вумные указатели

[Igors]

Добрый день

Запутался с, казалось бы, простой задачей. Есть 2 мапы

Код

C++ (Qt)
std::map<Key1, Value *> map1;
std::map<Key2, Value *> map2;
 

Обе мапы хранят полный (и одинаковый) набор Value. В первой мапе эл-ты с разными ключами могут иметь одно и то же значение. Во второй все значения уникальны (а не только ключи). Др словами первая - чтобы собственно пользоваться, вторая - чтобы "валидировать".

Клиент, располагая 2-мя ключами, ищет 2 значения Value в map1 и map2. Если они ненулевые и совпали - все хорошо, возвращается найденный указатель. Иначе если эл-т не найден в map2 то новый Value должен быть создан и помещен в обе мапы. Если найден то замещает значение в map1[key1]. В любом случае если оказалось что старый (замещаемый) эл-т в map1 больше в ней никем не используется - значение должно быть удалено и вычеркнуто из map2. Др словами обе мапы все время должны хранить полный и одинаковый набор значений.

Как же здесь могут помочь вумные указатели? 

Спасибо

[ssoft]

Можно хранить в map2 shared_ptr< Value >, а в map1 weak_ptr< Value >, тогда удаление Value из map2 приведет к обнулению указателя weak_ptr в map1.
Только это кажется нерациональным, так как пустые weak_ptr "зависнут" в map1, но все зависит от контекста решаемой задачи.

[Igors]

Можно хранить в map2 shared_ptr< Value >, а в map1 weak_ptr< Value >, тогда удаление Value из map2 приведет к обнулению указателя weak_ptr в map1.
Только это кажется нерациональным, так как пустые weak_ptr "зависнут" в map1, но все зависит от контекста решаемой задачи.

Ну вот, есть же люди которые нормально отвечают, не ссылаясь на "плохая задача"! У меня удаление по Key1 (клиент отвалился), поэтому сделал наоборот, shared в первой, weak во второй (суть та же). А вот с удалением зависших ключей ничего не придумал Не видно особой опасности, но как-то неаккуратно. Может в самом Value хранить итератор map2? Хорошего впечатления не производит... 

[ssoft]

Может в самом Value хранить итератор map2? Хорошего впечатления не производит... 
[/quote]

После изменения состава map2, хранимый итератор может стать невалидным.

[Igors]

После изменения состава map2, хранимый итератор может стать невалидным.

Для мапы остается валидным пока сам элемент не удален. Все равно коряво

[Racheengel]

По моему, указатели тут не помогут. Лучше дедовским методом прибить значение в  map2 и не париться...

[Old]

По моему, указатели тут не помогут. Лучше дедовским методом прибить значение в  map2 и не париться...

А если удаляемые элементы кому-то еще нужны, а мы их будем грохать?
Тут умные указатели как раз очень нужны.

[Igors]

По моему, указатели тут не помогут. Лучше дедовским методом прибить значение в  map2 и не париться...

Т.е. пробегаться по map2 и мочить всех с пустыми значениями? А в какой момент это делать?

[Old]

А в какой момент это делать?

У меня удаление по Key1 (клиент отвалился)

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

[Racheengel]

По моему, указатели тут не помогут. Лучше дедовским методом прибить значение в  map2 и не париться...

А если удаляемые элементы кому-то еще нужны, а мы их будем грохать?
Тут умные указатели как раз очень нужны.

Я так понял, что если значения в мапе больше нет - его можно убить, т.к. оно никому не нужно.

[Igors]

Я так понял, что если значения в мапе больше нет - его можно убить, т.к. оно никому не нужно.

И даже нужно. Но как и, главное, когда это делать? Удаление клиента по Key1 ни о чем не говорит, ведь могут быть другие, юзающие тот же Value

[m_ax]

У shared_ptr есть метод unique: http://en.cppreference.com/w/cpp/memory/shared_ptr/unique
а также use_count.

[Igors]

У shared_ptr есть метод unique: http://en.cppreference.com/w/cpp/memory/shared_ptr/unique
а также use_count.

И что, как я найду удаляемый в map2? На момент удаления имеется только Key1. Неиспользуемый может удаляться и в момент создания нового. Тогда есть оба ключа, но это не помогает - нашли Value по Key1, а по Key2 нет.

Смысл этой конструкции 2 мапов: есть кеши рисования (Value) которые могут шариться. Напр 2 рисуемых объекта шарят один кеш, 2 ключа (Key1) ссылаются на 1 Value. Теперь юзер что-то изменил в одном из рисуемых объектов, и теперь уже нужно 2 кеша. Вот для этого и нужна map2. Если по ключу Key2 (параметры влияющие на рисовние) ничего не найдено в map2, то новый кеш должен быть создан и мапы обновлены.

[Old]

Смысл этой конструкции 2 мапов: есть кеши рисования (Value) которые могут шариться. Напр 2 рисуемых объекта шарят один кеш, 2 ключа (Key1) ссылаются на 1 Value. Теперь юзер что-то изменил в одном из рисуемых объектов, и теперь уже нужно 2 кеша. Вот для этого и нужна map2. Если по ключу Key2 (параметры влияющие на рисовние) ничего не найдено в map2, то новый кеш должен быть создан и мапы обновлены.

Как то это напоминает implicit sharing, но странно реализованным.

[Авварон]

Плохо соображаю под вечер, но не мультииндекс ли это?