Re: any_function (callback) library

From: williamkempf_at_[hidden]
Date: 2001-04-09 10:09:58

--- In boost_at_y..., "Geurt Vos" <G.Vos_at_r...> wrote:
> 
> First, sorry for not replying sooner. I just realized you were
> working on this.
> 
> I've been working on a callback class for some time now, and 
> next to the obvious goals, there are two more requirements
> I'm trying to meet:
> 1. the class should be extendable
> 2. it should be easy to extend
> 
> Both these criteria are not met by the any_function
> implementation.
> 
> 
> > 
> > ------------------------------
> > Interface summary:
> > 
> >   template<typename Result, typename Arg1, typename Arg2, 
> > ..., typename ArgN>
> 
> The main problem with this approach is that it isn't extendable.
> I mean, how many parameters to support? as I view the code, it's
> implemented for up to 6 parameters, which is in my opinion enough
> (my 'previous version' had this approach for up to 5), but I 
> guarantee you someone will require 7. The largest implementation
> I've seen so far is Alexandrescu's Functor class: a massive 15 
> parameters (the one in Modern C++ Design). 

This argument has been made on this list in the past.  Both sides 
have valid arguments, IMHO, making this a very sticky design decision 
to deal with.

> Imagine the error message you'll get when the number of required
> parameters isn't met, and any_function is called with either one
> argument more or one less.......
> 
> 
> >   class any_function
> 
> why not 'class callback', and why only functions and functors,
> and not also function members? 

This, too, was discussed on this list at length.  The name 'callback' 
is just not as all encompassing as what the class is.
 
> >     bool empty() const; // true if no target
> >     operator const void*() const; // evaluates true if non-empty
> > 
> 
> Again, I'm not certain whether both are required.
> I personally would lose the operator...

The operator allows for seemless replacement with traditional C 
style "callbacks".  I'm not at all sure that I'd lose the operator 
here.

> Lastly, I'm not sure whether or not the distinction between
> invoker and void_invoker is done for compatibility with
> older compilers. Anyway, note that the following code is
> legal C++ code:
> 
> void f1();
> void f2()
> {
>     return f1();
> }

The documentation explains this nicely.  Whether the above is legal 
or not doesn't matter... many compilers get this one wrong still.
 
> --------------------------------------------------
> Up until now I only said what's 'wrong' with any_function,
> of course I should also provide some solutions. First, I
> can make my solution available, should I simply upload it
> to groups.yahoo.com/boost?
> 
> Anyway, the declaration of the callback is as following
> (omitted namespaces for brevity):
> 
> Callback<CxParam<Param0,...,Paramx,Result,validate> > instance;
> 
> 'x' is the implementation for a specific number of
> parameters. I have it implemented for 0 to 5.
> Result defaults to 'void' and validate to 'true'. 
> If 'validate' is true, a call to operator() will 
> first check whether a function is attached and if
> not, return Result();

This doesn't solve the "fixed number of parameters" problem, unless 
I'm missing something drastic here.  I also think it would be more 
appropriate to throw than to return Result(), and can think of no 
valid reason to ever use validate=false.
 
> Callback will inherit from CxParam<>, and CxParam will
> inherit from CallbackHolder<StoragexParam>. StoragexParam
> is a class template, which has two nested classes: one for
> the interface (with only operator() as virtual func) and
> one for storing a pointer to the actual function (which is
> either a function, function object or a function member).

Ahh... this helps to figure out how you eliminated the fixed number 
of parameters, but I'd have to see all of the implementation to fully 
comprehend this.  However, you've added in virtual methods here, 
which was specifically avoided in any_function (again, read the 
documentation).  It's being used in a slightly different location so 
may not be prone to the same problems being avoided here, but it 
still throws up red flags for me.
 
> I'm not sure whether this all makes sense until you've
> seen the code....just let me know where I should make it
> available...

Anyone can upload to the Boost files section.
 
> The two criteria I mentioned at the beginning of this mail
> I think have been met quite nicely with this implementation.
> I can make it even easier by using virtual inheritance at 
> two place, but I didn't want to touch that yet :) 

It appears that you've also made the interface more complex to use, 
which is a bad thing IMHO.  I'd love to see the actual implementation 
so I could better evaluate it, though.

Bill Kempf