$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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