Re: New New Callbacks Uploaded

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 <v03110700b641067df0b8@[153.32.222.4]>, Jesse Jones
> <jejones_at_a...> writes
> >I've uploaded a new version of my callback classes (see the 
Callbacks2
> >directory in the vault). Like Doug Gregor's this version has the 
nice
> >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 
seems
> to open up the possibility of runtime errors and require that all 
result
> types are default constructible. I don't think either of this, esp 
the
> 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;

instead of:

callback2<void, int, float> cb;

> As another point, is there a reason that pointers are restricted to 
raw
> pointers? This restriction is not necessary -- see 
http://www.cuj.com/ex
> 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.

Bill Kempf