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 <firstname.lastname@example.org>, Jesse Jones
> <jejones_at_a...> writes
> >I've uploaded a new version of my callback classes (see the
> >directory in the vault). Like Doug Gregor's this version has the
> >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
> to open up the possibility of runtime errors and require that all
> types are default constructible. I don't think either of this, esp
> 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;
callback2<void, int, float> cb;
> As another point, is there a reason that pointers are restricted to
> pointers? This restriction is not necessary -- see
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk