The short and unfortunate answer is that while shared_ptr<>
can be used safely as a key in an unordered set or map, weak_ptr<>
cannot and must not. No amount of trickery can make it safe.
This is because weak_ptr
's interface does not expose access to the shared control object, which is the basis of comparing by owner_before()
when used in an ordered set or map.
While it may seem reasonable to lock the pointer and then hash the shared_ptr
, it is not. If the last shared_ptr
goes out of scope the hash value will change, which will result in undefined behaviour next time your set or map is iterated. This will most likely go un-noticed until your code is in production in front of customers where you get unexpected and inexplicable loss of functionality occasionally, but your unit tests will still pass flawlessly, giving you the false idea that your test coverage is good, your code is reliable and it is the users, hardware or network that's to blame.
So, in summary, if you're going to use weak_pt
r's to build your non-owning object caches (for which they are excellent) you need use a std::set<weak_ptr>
and suffer the miniscule performance hit (although in reality this will be dwarfed by the performance loss caused by the mutex
that protects the set).
If you really want to use a weak_ptr
as an unordered key you will have to write your own (hint: use the address of the shared control block as the basis for the hash function).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…