From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-27 14:45:39
On Tuesday 27 August 2002 12:18 pm, Peter Dimov wrote:
> If we really need the above to be supported, the right approach is:
> * mem_fn must recognize weak_ptr and either perform
Or just let the precondition on mem_fn's operator() be:
get_pointer(x) != 0
and rely on the get_pointer overload for weak_ptr. It's not much different
than calling this illegal:
> or call X::foo only when x is nonzero, and silently do nothing otherwise
> (but this is only applicable to void functions.)
I'd shy away from this type of behavior, because it could get quite confusing,
especially because the result of mem_fn is generally passed to template
> (I'm undecided whether this coupling is a good thing, and I'm not sure
> whether lack of partial ordering on some compilers may prove a problem.)
I wouldn't be overly concerned with partial ordering; it seems that problem
can be solved in a portable way with a few tricks. The easy solution
(get_pointer for weak_ptr) doesn't add any coupling that isn't already there.
> * The signal must recognize weak_ptr too; a weak_ptr tracks the object
> lifetime regardless of whether the object is-a trackable.
Right. The difference being that you have to 'poll' a weak_ptr to determine if
it is still connected or not.
> For this release, I think that we should leave mem_fn as is; if you decide
> to implement a signal that knows about weak_ptr, a temporary workaround
> would be to bind a forwarding function
> void foo(weak_ptr<X> const & px)
> instead of &X::foo.
I'm fine with holding off the changes for this release. weak_ptr support in
Signals does us no good if weak_ptrs can't be used by bind/mem_fn anyway.