On 07/01/2011 08:09 AM, Paul Mensonides wrote:
For better variadic support, what's needed most are a few low-level macros such as IS_VARIADIC (small change) and a variadic/placemarker sequence implementation (large, though possibly not difficult, change). This notion of a, b, c being a good way to store elements (which are possibly empty sequences of preprocessing tokens and whitespace separations) needs to die. I was just watching some of the Boostcon videos and in one of them (something like Haskell = C++ TMP) there are examples that utilize variadic templates to pass around lists of types. However, in the example, they are "open". I.e. not bounded by something that collects them as a singular entity. I don't have it in front of me, but something like:
template<class, class... T> struct count { enum { value = 1 + count<T...>::value }; };
template<> struct count<> { enum { value = 0 }; };
...but this is terrible. It doesn't take away from the point of the talk, but it should be something like count<typelist<A, B, C>>, not count<A, B, C>.
Yes, if I remember well Dave made a comment like that during the talk and I think they agreed it would probably be a better mapping but that he wanted to keep things simple for the presentation. When you try to map functions to meta-functions, it's best if a single "list" argument stays a single "typelist" argument as well. Otherwise you have obvious problems when you want to pass multiple lists to a function. There are a couple of languages, though, where calling a function with a list of N arguments is the same as calling it with N arguments, and there is no way to pass two distinct lists within using a delimiter argument. CMake is an example of this.