Why was std::hash not defined for std::weak_ptr in C++0x?

Question

After reading the discussion on operator< for std::weak_ptr, I can't see any reason why defining std::hash to use the control block for std::weak_ptr wouldn't work. I also can't believe that this was ignored by the standards committee. Has anybody read the relevant discussion on the topic?

Edit: Discussion on operator< for std::weak_ptr http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1590.html

Ticktack

Answer 1

I am somewhat familiar with the history. There's another later paper you should also read:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf

And I believe this later paper is what is actually in the current draft. In summary, shared_ptr has value-based operator<() and ownership-based member functions owner_before. weak_ptr has only the latter.

My best guess is that hash-support for weak_ptr simply got dropped. No one proposed hash support for weak_ptr to the best of my knowledge. There have been many, many issues in bringing C++0x to standardization, a limited amount of time and resources to work the issues, and no doubt there will be mistakes and missing pieces.

I also think to add hash support for weak_ptr it would have to be done analogously to owner_before: Add the member function owner_hash to both shared_ptr and weak_ptr. I suspect it is too late to do this for C++0x, but this seems like a plausible TR2 proposal.

Spireme

It turns out that Japan actually reported this. – Loreenlorelei

So ... those of us who need to hash a weak pointer, and are too lazy to figure it out ... what code should we write? – Compassionate

I see no way to write this function as a client as described above with owner_hash. Clients simply don't have access to the field that needs to be hashed. This can only be provided by the std::lib implementor. I do not know how a client could write a non-error-prone hash function for weak_ptr. Maybe someone else has a good idea... – Spireme

Answer 2

It turns out that Japan complained about this (see lwg issue 1406), and that exactly what Howard suggests in his answer was proposed as the resolution. Unfortunately, it was postponed (presumably because of time constraints).

Loreenlorelei