Re: [boost] Signals & slots library prototype

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-04 10:01:15

On Wednesday 04 July 2001 10:10, you wrote:
> From: "Douglas Gregor" <gregod_at_[hidden]>
>
> > On Wednesday 04 July 2001 07:36, you wrote:
> > > Could you please describe your modifications in more detail? bind.hpp
> > > is still a work in progress. From what I can see, you've added some
> > > inline functions that can easy go in a separate header; anything else
> > > that I've missed?
> >
> > That's about it. The changes could go in a separate header but it's a
> > dangerous thing to do: if a user includes bind.hpp but not the separate
> > header, everything will seem to work but the signals won't know about any
> > bound objects; there isn't a very good way to warn the user about this.
>
> Since
>
> > visit_bound_objects is such a small bit of code, I'd prefer if it were
>
> always
>
> > included in the primary binder library header.
>
> Agreed. I see that you've also changed _bind<> a bit to make the data
> members public. I'd rather add a 'visit' member, but I'm not sure how VC++
> would like that.

It should work well with it. So far I've found that VC++ does member 
templates relatively well so long as the return type is "easy".

> > It's the function of visit_bound_objects (and its associated visitor
>
> concept)
>
> > that I would like to discuss. Essentially, signals & slots needs the
>
> ability
>
> > to access each of the bound objects in a slot (slot = any function
>
> object). I
>
> > chose to use a visit_bound_objects free function that takes the function
> > object and a visitor, and calls a method in the visitor for each bound
> > object.
>
> This is a good approach. I wonder whether it should be generalized, i.e.
> rename visit_bound_objects to just 'visit' and define a set of requirements
> that an object should conform to to be 'Visitable'.

This starts to get close to a more general reflection framework. Not that 
there is a problem with that, but it's a big undertaking.

> > There are lots of open issues, the most important of which are:
> > - References: can't tell them apart from by-value at the moment. Perhaps
>
> it
>
> > is best to add a "visit_reference" member to the visitor concept.
>
> 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.

#2 just keeps a constant reference to x. Now since x can be destroyed 
regardless of the state of the function object, we want to visit x.

> > - User-defined pointer types: we need to know where a given object is
>
> hiding
>
> > inside a user-defined pointer type, and how to access it. This is perhaps
>
> a
>
> > separate issue, but is necessary nonetheless.
>
> I don't get that either. :-)
>
> --
> Peter Dimov
> Multi Media Ltd.

We know that we want to visit the objects pointed to by a pointer (because 
the pointer can be deleted). This can be recognized easily by the visitor. 
For instance, if we have:

struct X : public bindable {
  void foo();
};

X x;
sig.connect(bind(&X::foo, &x));

The visitor can find out if the object is "bindable" using a base pointer 
conversion:

struct some_visitor {
  void visit(bindable* b) { /* ... */ }
};

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.

        Doug