Re: considerations regarding active issue #711 (contradiction in empty shared_ptr)
On Jun 6, 7:39 pm, Rodolfo Lima <rodl...@gmail.com> wrote:
I fail to see an useful use case of the empty/non-null smart pointer,
it just doesn't make sense to me. I mean, an empty/non-null smart
pointer is no better than a raw pointer, why use the former when the
latter is simpler?
Because a program might need to pass a pointer to, say, a class member
object (or any object that is part of an encompassing allocation) when
an interface calls for a shared_ptr.
It boils down to what really is a smart pointer.
One fundamental concept is that it manage the pointer life time, be it
directly or indirectly through another smart pointer (the aliasing
case). For me the empty/non-null case just doesn't fit in this
concept, as being empty implies it doesn't manage anything, so there's
no point in having a stored pointer (which would be unmanaged, which
is the contrary of the original fundamental concept).
Yes, the stored pointer of an "empty" shared_ptr is not managed by the
empty shared_ptr - but is instead managed (indirectly) by the
shared_ptr it aliases.
Furthermore, under either proposed fix for #711, the assert() in your
original program can fail (when the aliased shared_ptr is not empty).
For example:
// aliasing shared_ptr
shared_ptr<int> aux(new int);
int i;
shared_ptr<int> sptr(aux, &i);
weak_ptr<int> wptr;
if (sptr)
{
wptr = sptr;
assert(wptr.lock() == sptr); // assertion failure!
}
Essentially, attempting to monitor an empty, aliased shared_ptr with a
weak_ptr will always fail - no matter how Issue #711 is resolved.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]