Re: [boost] New New Callbacks Uploaded

From: Douglas Gregor (gregod_at_[hidden])
Date: 2000-11-22 11:54:14

On Wed, 22 Nov 2000 07:04:04 +0000
Kevlin Henney <kevlin_at_[hidden]> wrote:

> In message <v03110700b641067df0b8@[153.32.222.4]>, Jesse Jones
> <jejones_at_[hidden]> 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.

In this set of callback classes, it does allow runtime errors (an incorrectly used callback will compile, but fail an assertion the first time it is invoked). The culprits here are the three virtual functions in base_call_functor - these also tend to make callbacks artificially large and require that the return type be default-constructible. IMHO, base_call_functor should be split into separate classes depending on the number of arguments, so that only one virtual function would be included in the vtable, and could be abstract (thus making incorrect usage a compile-time error, shrinking the vtable, and removing the default-constructible requirement) - this is the approach that I chose, so I'm a bit biased.

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

I'll stick my neck out to say that most of us are under the assumption that callbacks will be used with a more powerful library (e.g., Lambda) instead of attempting to duplicate its functionality. 

        Doug Gregor