Re: [boost] Re: New New Callbacks Uploaded

From: Douglas Gregor (gregod_at_[hidden])
Date: 2000-11-23 10:34:20

On Wed, 22 Nov 2000 19:37:53 +0000
Kevlin Henney <kevlin_at_[hidden]> wrote:

> In message <8vgkjo+102eg_at_[hidden]>, 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.

This is not an issue, and here is why:
Even though the callback class has many operator() overloads, the abstract implementation class takes its one virtual operator() overload from a specialization based on the number of used arguments. Calling an operator() with the wrong number of arguments will result in a compile-time error because the virtual operator() with that number of arguments doesn't exist. Assignment of a functor with the wrong number of arguments is also blocked at compile-time because of this.
 
> >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.
> 
> It should be possible, with appropriate specialisations, to make the
> unwanted overloads of the callback unusable for a given number of
> arguments.

They are unusable, and it is possible to have callback<> only contain the appropriate operator().

> 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.

Only one virtual is used in my implementation and (again) legal use is already enforced. Jesse's implementation uses some metaprogramming to simplify the code. If indeed that level of metaprogramming is portable, this is IMHO the best way to go.

        Doug Gregor