Re: [boost] Signals & slots library prototype

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-04 10:18:28

From: "Douglas Gregor" <gregod_at_[hidden]>
> > I'm not sure that I follow. Why would you want to treat references
> > differently?
>
> A typical fallback "visit" method of a visitor might be:
> void visit(const bindable& b) { /* ... */ }
>
> How does one tell if "b" is bound as a reference or as a value? If it is
> bound as a reference, we should be watching for b's destruction. However,
if
> it's bound as a value, we don't care when it is destroyed (because the
whole
> function object will have been destroyed). It's the difference between #1
and
> #2 in:
>
> struct X : public bindable {};
> void foo(const X&);
>
> X x;
> sig.connect(bind(&foo, x)); // #1
> sig.connect(bind(&foo, cref(x)); // #2
>
> #1 makes a copy of "x" and stores is. The signal doesn't care about the
> lifetime of the copy, because the copy obviously has the same lifetime as
the
> function object itself.

True, but tracking the copy lifetime as well is harmless, isn't it?

You can recognize _value<T&> with boost::is_reference. I'm not sure whether
it works on VC++ (I think it does.)

Of course bind.hpp uses lv() instead of ref()/cref(), but this is not a
problem.

> However, this is not the case if a smart pointer is used:
>
> boost::shared_ptr<X> y = new X();
> sig.connect(bind(&X::foo, y));
>
> How does the visitor know that shared_ptr<X> is a pointer to an X, and X
> derives from bindable? It's a separate but important question, and
probably
> one that will pop up elsewhere. Perhaps the generalized "visit" you
mentioned
> would solve this question as well.

That was what I had in mind, yes. If shared_ptr<> is Visitable, you'll
simply visit() it.

--
Peter Dimov
Multi Media Ltd.