How can you efficiently check whether two std::weak_ptr pointers are pointing to the same object?

Question

I want to compare two std::weak_ptr's or one std::weak_ptr and one std::shared_ptr for equality.

What I want to know is whether the object each of the weak_ptr's/shared_ptr's point to is the same. The comparison should yield negative results not just if the addresses don't match, but also if the underlying object was deleted and then reconstructed with the same address by chance.

So basically, I want this assertion to hold even if the allocator reserves the same address:

auto s1 = std::make_shared<int>(43);
std::weak_ptr<int> w1(s1);

s1.reset();

auto s2 = std::make_shared<int>(41);
std::weak_ptr<int> w2(s2);

assert(!equals(w1,w2));

The weak_ptr templates do not provide equality operators, and as I understood that's for a good reason.

So a naive implementation would look like this:

template <typename T, typename U>
inline bool naive_equals(const std::weak_ptr<T>& t, const std::weak_ptr<U>& u)
{
    return !t.expired() && t.lock() == u.lock();
}

template <typename T, typename U>
inline bool naive_equals(const std::weak_ptr<T>& t, const std::shared_ptr<U>& u)
{
    return !t.expired() && t.lock() == u;
}

If the first weak_ptr expired in the meantime, it yields 0. If not, I upgrade the weak_ptr to a shared_ptr and compare the addresses.

The problem with this is that i have to lock the weak_ptr's twice (once)! I'm afraid that takes too much time.

I came up with this:

template <typename T, typename U>
inline bool equals(const std::weak_ptr<T>& t, const std::weak_ptr<U>& u)
{
    return !t.owner_before(u) && !u.owner_before(t);
}


template <typename T, typename U>
inline bool equals(const std::weak_ptr<T>& t, const std::shared_ptr<U>& u)
{
    return !t.owner_before(u) && !u.owner_before(t);
}

Which checks if the owner block of u is not "before" t's and t's not before u's, so t == u.

Does this work as I intend it? Do two weak_ptr's created from distinct shared_ptr's always compare as non-equal this way? Or did I miss something?

Edit: Why do I want to do this in the first place? I want to have a container with shared pointers, and I want to hand out references to the objects in it. I can't use iterators, since they may be invalidated. I could hand out (integer) ID's, but that leads to problems with uniqueness and would require a map type and complicate search/insertion/removal operations. The idea is to use a std::set and give out the pointers themselves (capsuled in a wrapper class) as keys, so that clients can use the weak_ptr's to access the objects in the set.

Buonaparte

"as I understood that's for a good reason." If you understand that this is for a good reason, then why do you want to do this? – Tineid

I just hit this problem in a concurrent app and good thing owner_before() exists. For my use case, comparing the control blocks was the only sensible answer. – Declamation

Answer 1

Completely rewriting this answer because I totally misunderstood. This is a tricky thing to get right!

The usual implementation of std::weak_ptr and std::shared_ptr that is consistent with the standard is to have two heap objects: the managed object, and a control block. Each shared pointer that refers to the same object contains a pointer to the object and to the control block, and each weak pointer likewise. The control block keeps a record of the number of shared pointers and the number of weak pointers, and deallocates the managed object when the number of shared pointers reaches 0; the control block itself is deallocated when the number of weak pointers also reaches 0.

This is complicated by the fact that the object pointer in a shared or weak pointer can point to a subobject of the actual managed object, e.g. a base class, a member, or even another heap object that is owned by the managed object.

S0 ----------______       MO <------+
   \__             `----> BC        |
      \_ _______--------> m1        |
     ___X__               m2 --> H  |
S1 -/      \__ __----------------^  |
    \___ _____X__                   |
    ____X________\__                |
W0 /----------------`---> CB -------+  
                          s = 2 
                          w = 1 
                               

Here we have two shared pointers pointing respectively to a base class of the managed object and to a member, and a weak pointer pointing to a heap object owned by the managed object; the control block records that two shared pointers and one weak pointer exist. The control block also has a pointer to the managed object, which it uses to delete the managed object when it expires.

The owner_before / owner_less semantics are to compare shared and weak pointers by the address of their control block, which is guaranteed not to change unless the pointer itself is modified; even if a weak pointer expires because all shared pointers have been destructed, its control block still exists until all weak pointers have also been destructed.

So your equals code is absolutely correct and thread safe.

The issue is that it's not consistent with shared_ptr::operator== because that compares the object pointers, and two shared pointers with the same control block can point to different objects (as above).

For consistency with shared_ptr::operator==, writing t.lock() == u will be absolutely fine; note however that if it returns true then it's still not definite that the weak pointer is a weak pointer of the other shared pointer; it could be an alias pointer and so could still expire in following code.

However, comparing control blocks has less overhead (because it doesn't need to look at the control block) and will give the same results as == if you're not using alias pointers.

---

C++26 is highly likely to add owner_equal and owner_hash function object templates, allowing the use of weak_ptr as key type in unordered containers. Given owner_equal it actually becomes sensible to compare weak pointers for equality, as you can safely compare the control block pointer then the object pointer, since if two weak pointers have the same control block then you know that either both or neither are expired.

Stool

Thanks, I completely forgot about multithreading although it definitely has to be regarded for my application. What I am really intersted in is comparison to a shared_ptr. Would (w.lock() == s) be sufficent as a comparison? w.lock() is atomic and once it's locked, none of the pointers can't expire. Would that work? – Buonaparte

Thank's for the elaborate reply. I think checking for the equality of the control block address should be efficient enough. Since owner_before() has an overload for shared_ptr, I can use the latter version for both comparisons. – Buonaparte

By the way, the Microsoft guy found a way to omit the pointer in the control block with his "we-know-where-you-live"-optimization, by allocating the actual object within the control block. Also check out the slides, on his 4. slide there is a neat diagram of the "usual" implementation. – Buonaparte

Thanks, some good afternoon reading there! The we-know-where-you-live optimization can't always be used, as it's still possible to construct a shared_ptr to a newed pointer; incorrect in new code, which should be using make_shared, but useful for adding safety to existing legacy code and interfaces. – Stool

I totally agree about owner_hash and owner_equals. I think something like this could help: template <typename T> class comparable_weak_ptr { const T* m_original; std::weak_ptr<T> m_weak; public: comparable_weak_ptr(std::shared_ptr<T> shr) : m_original(shr.get()), m_weak(std::move(shr)) {} bool operator==(const std::shared_ptr<T>& shr) const { return (shr.get() == nullptr && m_original == nullptr) || shr.get() == m_original && shr == m_weak.lock(); } }; – Younger

What if you have a weak_ptr referring to a sub-object? Won't it then compare as equal to a weak_ptr (or shared_ptr) referring to the whole object or any other sub-object? – Sean

@ChrisDodd yes, it would; I believe that would be satisfactory to OP in this case. – Stool

@Younger @ecatmur: There is in fact a proposal (P1901R2) for adding owner_hash and owner_equal, which has been approved to be included in C++26, see: github.com/cplusplus/papers/issues/649. It's already integrated in the current draft of the standard, see: mem.syn. – Citrange