From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-22 16:03:37
--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <8vgkjo+102eg_at_e...>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >I've not looked at Jesse's new code yet, but Doug's code doesn't
> >to open up the possiblity of runtime errors that you suggest.
> >Neither does it require that any parameters or other types be
> >constructible. Care to elaborate on the problems you think you
> The compile-time interface to the callback class offers versions of
> operator() that cannot be satisfied at runtime.
Again, I won't comment on Jesse's implementation, but it's possible
to implement this idiom with the result of it being a compile time,
not run time, error to use an erroneous operator() overload.
> >As for why it's desirable... it eliminates redundant information
> >the declaration. Why should you have to specify the number of
> >parameters when you declare the type with explicit parameters?
> >just cleaner to say:
> >callback<void, int, float> cb;
> >instead of:
> >callback2<void, int, float> cb;
> I understand that the syntax is desirable, but I don't think it
> be at the expense of safety.
I'd agree, but I don't see safety issues here.
> It should be possible, with appropriate specialisations, to make the
> unwanted overloads of the callback unusable for a given number of
It doesn't really even require specializations, though it does
require some meta programming. Doug's version is already safe in
> Another thought: Would it be possible to do a little currying to
> the way that extra arguments are handled internally? This would
> benefit of (1) enforcing only legal use, (2) simplifying the
> implementation, and (3) keeping the size of classes and number of
> virtuals flying around to a minimum.
Again, I think Doug's addressed this fairly well. There may yet be
some tricks to reduce code bloat in his implementation, but in
general it's satisfactory now.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk