Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-22 09:18:32


--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <v03110700b641067df0b8@[153.32.222.4]>, Jesse Jones
> <jejones_at_a...> writes
> >I've uploaded a new version of my callback classes (see the
Callbacks2
> >directory in the vault). Like Doug Gregor's this version has the
nice
> >property of not requiring clients to encode the number of
arguments in the
> >callback class name.
>
> I might be missing something, but why is this a nice property? It
seems
> to open up the possibility of runtime errors and require that all
result
> types are default constructible. I don't think either of this, esp
the
> first point, is really that desirable.

I've not looked at Jesse's new code yet, but Doug's code doesn't seem
to open up the possiblity of runtime errors that you suggest.
Neither does it require that any parameters or other types be default
constructible. Care to elaborate on the problems you think you see?

As for why it's desirable... it eliminates redundant information from
the declaration. Why should you have to specify the number of
parameters when you declare the type with explicit parameters? It's
just cleaner to say:

callback<void, int, float> cb;

instead of:

callback2<void, int, float> cb;

> As another point, is there a reason that pointers are restricted to
raw
> pointers? This restriction is not necessary -- see
http://www.cuj.com/ex
> perts/1811/henney_x.html which allows other smart object pointers.

No, there's no reason. I'm currently working on yet another
implementation that uses these techniques.

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk