Я наблюдал по меньшей мере с пяток таких попыток, но у всех были свои неудобства.

Это уже человеческий фактор, с философией босяка ("работать позорно") бороться бесполезно

Да, и ошибку-то все-таки покажите 

Никак, в данном случае это неизбежно. Но тулить итераторы всегда и везде (напр даже когда есть индекс) - перегиб

Однако вернемся к Hash/Set. Поскольку базовые контейнеры (QHash/QSet) НЕ thread-safe, то очевидно что и порожденная конструкция тоже. Нужно засисяться локерами, причем как-то непросто. Но сначала нужно убедиться что с одной ниткой работает (корректна ли затея с итератором?). Не слышу критики (только ssoft), все вокруг да около..

Тоже заглянул в пример .


А если после удаления CSharedHash/Set будут существовать шареды, запихнутые методом Put с тем кастомным Deleter, что в примере, они потом тоже могут быть безболезненно удалены?

Вас в гугле забанили?=)


Но, кстати:
Это упростит жизнь и вместо вытиратора можно хранить ссылку на пару ключ/значение.

Указатель raw должен быть сугубо ключом, и ни в коем случае нельзя через него осуществлять доступ к членам (обращаться с ним, как с указателем). Даже если он "протухнет", соответствующее ему weak значение станет нулевым.

Действительно, это железобетонная защита, ни один гейзенбаг не проскочит .


Теперь Deleter по-настоящему полезным делом занят, без него никак .

охохохо, свершилось!

В общем случае - нет. Weak не контролирует свое состояние!
Предположим, есть ассоциативный массив, в качестве ключа которого используется weak. Узлы такого массива упорядочены между собой исходя из определенного правила сравнения ключей (оператор <, хеш или др.) и свойства их постоянности. Если каким-либо внешним способом (например, weak) изменить значение ключа в узле ассоциативного массива, то существующее упорядочивание узлов станет не корректным, и от ассоциативного контейнера можно ожидать непредвиденного поведения.

Если же следить за тем, чтобы weak был корректным, то исчезает сам смысл использования weak. С таким же успехом можно хранить raw с меньшими потерями на data race.

Data race возникает из-за того, что в связке shared/weak используется, как минимум, два атомарных счетчика, которые постоянно инкрементируются и декрементируются при преобразованиях weak<->shared или копировании shared. Конкурентные операции с атомарными счетчиками приводят к частому сбросу процессорного кэша и иногда к существенному к замедлению. С raw такого эффекта не возникает. Если нужно через raw указатель получить shared, то можно использовать либо ассоциативный массив вида {raw, weak}, либо использовать наследование от std::enable_shared_from_this (https://ru.cppreference.com/w/cpp/memory/enable_shared_from_this).

PS: Если есть возможность использовать std вместо Qt, используйте std. Решения Qt были сформированы, когда в std был недостаточно развит. Теперь же функциональность std по базовым вещам превосходит Qt, притом существенно. Именно поэтому Qt рассматривает вопрос о прекращении поддержки своих решений в пользу стандартных.