Boost logo

Boost :

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
>
> (shared_ptr<X>(x)->*&X::foo)();

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:

  mem_fn(&X::foo)(static_cast<X*>(0));

> 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
functions...

> (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)
> {
> shared_ptr<X>(px)->foo();
> }
>
> 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.

        Doug


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk