Re: [boost] weak_ptr triple states

From: Jaap Suter (boost_at_[hidden])
Date: 2005-07-14 14:54:10

>> a weak_ptr can be said to have three states.

>> 1. Never been assigned to (default constructed)
>> 2. Assigned to, lock will return a shared_ptr to a valid object.
>> 3. Assigned to, but the object pointed to is dead and lock will
>> return null.

> There is no particular reason to make 1 and 3 indistinguishable. You are
> right that weak_ptr could have provided an "is empty" query in addition to
> expired(). There just aren't any compelling use cases for it, as far as I
> know.

Are there compelling reasons not to add such a member function, i.e. a
different shared_ptr implementation wouldn't be able to provide such a
function?

A friend of mine actually came up with a use case in his code, which is what
prompted this question. In pseudo-code, it looked like this:

struct guarded_memory
{
    void*          memory;
    weak_ptr    guard;

    guarded_memory(void* m)
        : guard(), memory(m) {}
    guarded_memory(void* m, weak_ptr g)
        : guard(g), memory(m) {}

    void access()
    {
        if (guard.never_been_assigned_to_before())
        {
            // no guard means always accessible
            do_something_with(memory);
        }
        else
        {
            if (shared_ptr p = guard.lock())
            {
                do_something_with(memory);
            }
        }
    }
};

Basically; if the user never provided a guard, the memory is deemed
accesible at all times, otherwise accessibility depends on the liveliness of
the pointed to guard.

In my opinion, the code is ackwardly assymetrical and not an example of
great design, but alas, it's what he came up with in some context.

The solution to the above code is too add a litle boolean that remembers
which of the two constructors has been called. This boolean is strictly
speaking redundant because weak_ptr already stores this information. Hence
my question.

Thanks,

Jaap Suter