Date: 2001-05-08 16:10:45
--- In boost_at_y..., John Max Skaller <skaller_at_o...> wrote:
> > > template <typename FUNCTOR,
> > > typename RETURN_TYPE,
> > > typename ARG1,
> > > typename ARG2,
> > > bool useCompare>
> UGGHH :-)
> You can get rid of functions of more than one
> argument. They don't exist in mathematics, and they
> shouldn't exist in C++ either.
I hardly agree, and you'll find most programmers (C++ or any other
language) will disagree with you here as well. Programming ain't
> Use the below C program to generate the template
> struct_n<class T1, class T2, .. class Tn>
> for all n up to a value given on the command line.
This only complicates usage. All you've done is changed the syntax
(making it harder to use in the end) while the semantics remain the
same. Multiple parameters are still being passed, they're just
packaged up into a single type. Though there can be a benefit to
doing this for some things, it's not a good general solution.
> Use these structures to pass multiple arguments.
> It is MUCH better to put the complexity of multiple
> arguments into exactly one place, namely the constructors
> of the type 'struct_n', and make everything else accept
> exactly one argument, than to try to handle functions
> of multiple arguments in function.hpp.
Again, this complicates usage severely. If I have a C style function
that takes 3 parameters I'd have to hand wrap this to take a single
struct_3 just to use boost::function, which defeats a good portion of
the reason for boost::function to even exist. To make this simple to
use we'd need some sort of boost::adapt_for_struct_n adaptor, which
would have the exact same "problem" you see in boost::function.
Besides, if you truly wanted to reduce this to a single argument
concept (again, you won't find much support for this from others)
you'd be much better off using the tuple concept then with using
these generated structures. At least from a usability standpoint...
there is a bit of an issue with compilation time concerns using
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk