RE: [boost] Re: any_function (callback) library

From: Geurt Vos (G.Vos_at_[hidden])
Date: 2001-04-10 08:21:04

> 
> In any case, what definition of type-strictness are you using? 

Well, I prefer no conversion at all, so only functions that exactly
match the signature are allowed. I can understand, though, that 
implicit conversions might be desirable, and casting is absolutely
undesirable. It can be dangerous from time to time, though. e.g 
using 'char' when 'int' is required. In the current implementation
of 'function',  there's no protection against this.  Maybe a policy
could solve it...

> > > > > ------------------------------
> > > > > 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.
> >
> > Hmm, the main problem with the current approach is that there's
> > _no_ way to extended it with e.g. policies. For instance, whether
> > or not to throw when no function attached. I mean, that would mess
> > up the default Argx declaration. I wouldn't want to declare it like:
> >
> > function<
> > 	void,
> > 	int,
> > 	detail::unusable,
> > 	detail::unusable,
> > 	detail::unusable,
> > 	detail::unusable,
> > 	nothrow
> >
> > > instance;
> >
> > Apart from undesirable, it now is impossible to add a new
> > (a 7th) parameter.
> >
> > So I simply think doing it this way is wrong, but hey,
> > that's just me...
> 
> I mentioned a possible resolution to this that I intend to try soon. The 
> policy/trait/etc classes would use named parameters and a generative 
> interface. The crux of the idea is that the above would be written as:
> 
> function<void, int>::nothrow instance;
> 
> The underlying implementation would (possibly) be based on function0, 
> function1, ... classes that do the actual work.
> 

An interesting idea, though user-defined policies/traits is still
a problem. Of course, -in this case- nothrow could be made a
template receiving whatever is appropriate. For instance:

function<void,int>::template exception<myException> instance;

which would throw myException when no function is attached...

> > One last thing: assigning a function will cause memory allocation.
> > copy construction/assignment doesn't, because reference counting
> > is used...
> 
> This was also debated at length. There was an overall 
> preference for the cloning.
> 

I agree when no memory allocation is required (as for 'function'),
then reference counting wouldn't really add anything.

> > > I'd love to see the actual implementation
> > > so I could better evaluate it, though.
> >
> > I'll have it uploaded to the boost file area.
> 
> Link?
> 

Tomorrow. I forgot to take the sources with me....

Geurt