Re: [boost] Signals & slots library prototype

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-04 11:33:12

On Wednesday 04 July 2001 11:18, you wrote:
> 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?

Actually, it isn't harmless. The visit is performed on the parameter to the 
connection routine (call it "slot"). Then "slot" is passed to the "set" 
routine of a boost::function object to handle the invocation where it is 
cloned. So if "slot" was a temporary, the connection will be disconnected 
when it goes out of scope.

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

Sorry :)

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

How far-reaching should the Visitable concept be? For instance, if I have:

struct X {};
struct Y { X* x; };

Should the "x" member of Y be visited when connecting a slot? It seems like 
the answer should be "yes" if Y is some sort of smart pointer, but "no" for 
most other uses. 

In some other context, there may be different requirements. A garbage 
collector might want to see all pointers and all subobjects, for instance. 
The Visitable concept would have to include some sort of filtering process.

        Doug