Boost logo

Boost :

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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at