Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-08-17 16:47:48

On Friday 17 August 2001 05:19, you wrote:
> Aside from the conflicts with functional -which I'm not sure how could be
> solved-, I vote for inclusion.
> I second the argument of replacing the _N notation for boost::argN.

I'll vote against boost::argN, because I think that the _N notation is
wonderfully terse and that it stands out well with syntax highlighting
available. In any case, it isn't a latent error: if one uses 1 instead of _1
or vice-versa, it will result in a compiler error.

> What I am not sure to accept is the visitor mechanism, it looks rather
> halfway to a more general callback coupling mechanism.
> Though I admit that I couldn't quite imagine the usage of 'accept' beyond
> the example given, I have the intuition that it provides a mecanishm that
> is not as carefully thought as the rest of the library. It could end up
> being a rather partial solution to a more general problem which might need
> to be addressed more deeply: the coupling of function objects and
> callbacks.

I can speak up for any shortcomings in the visitor mechanism. I've been
working on a signals & slots library. One of the requirements is that
connections between signals and slots only live as long as any of the objects
that are bound by either. For instance:

Button* closeAll = new Button(...);
Window* w1 = new Window(...);
closeAll->onClick.connect(bind(&Window::close, w1));
Window* w2 = new Window(...);
closeAll->onClick.connect(bind(&Window::close, w2));

If w1 or w2 is destroyed, the connection between closeAll->onClick and that
window object must be severed to avoid a segmentation fault. The signals &
slots library shouldn't define a bind member (creating function objects is
orthogonal to the callback mechanisms), so we need an external way to visit
each of the bound subobjects. The visitor mechanism was the only one
proposed, and we have yet to see a good, clean solution. Problems include:
  - want to minimize dependency between signals library and binding library
  - all function objects must be able to accomodate a visitor
  - shouldn't place this requirement on all function objects (otherwise it
would annoy users).

All solutions so far that decouple bind libraries from the signals library
have been deemed too brittle :(.

> BTW, which is the state of the preprocessor library?
> The implementation of bind seems a perfect candidate for it. As a user, I
> would require that the implementation of this particular library be
> readable enough so that if I need support for more than 9 arguments I can
> just go on and extend it. This task cold be very intuitive if the
> preprocessor is used. Alternatively, the documentation could include an
> 'extending the library for more arguments' section.
> Fernando Cacciola
> Sierra s.r.l.
> fcacciola_at_[hidden]


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