Re: [boost] Minor update to all _ptr headers

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