Boost logo

Boost :

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
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?
>
> 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
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;
>
> I understand that the syntax is desirable, but I don't think it
should
> 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
> arguments.

It doesn't really even require specializations, though it does
require some meta programming. Doug's version is already safe in
this regard.
 
> Another thought: Would it be possible to do a little currying to
wrap up
> the way that extra arguments are handled internally? This would
have the
> 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.

Bill Kempf


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