From: Mat Marcus (mat-boost_at_[hidden])
Date: 2003-11-17 13:18:01
--On Monday, November 17, 2003 1:50 PM +0100 Bernard
> It seems only logical to me when doing metaprogramming:
> You want to work with fonctions, so you have to know things about
> them (eg. number and types of arguments). Why would you not decide
> that every fonction should only take one argument ? Of course it
> would be a tuple. All the ugly code handling differents number of
> arguments (and limit on that number) would be factored in tuple.
> Other meta programming libs would know that they only have to
> handle one args, and they can then query about the number of
> elements in the tuple etc....
> Such a convention must be used across the board to be useful and
> this is not possible for classical dynamic C++, but if you are to
> decide convention for compile time C++, I do not see any reason not
> to do it.
> I would also define integral arguments to be wrapped in int_<>
> (uint_<> ) for consistency.
> I know it my sound strange, but I really think that such a
> "restricted" API would only be beneficial, because it would only
> give more powerful meta-programming.
Yes, there are a number of folks who have been working on making this
possible for some time. IMO, one aim of N1484, the type-safe variadic
proposal is to bring this goal closer to reality for regular C++
functions (and possibly also structs). We would like to be able to
write functions (and meta-functions for that matter) that accept a
single tuple/"parameter pack" (or struct) and programmatically walk
through the args/members (and/or their types). Furthermore it would be
desirable to be able to directly "uncurry" one of these tuples/"packs"
so as to be able to directly and apply foo() from some overload set
even if foo() is written using traditional
multiple-comma-separated-argument style. There is also a desire for
better syntax/support for tuple-like creatures in C++ '0x. Some of us
spent a bit of time discussing this in Kona and there *may* be an
enhanced version of
reflecting these ideas for the Sydney meeting.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk