Subject: Re: [boost] [preprocessor] Warning: Incoming
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2011-07-01 02:09:12
On Thu, 30 Jun 2011 21:31:22 -0400, Lorenzo Caminiti wrote:
> On Wed, Jun 29, 2011 at 10:54 AM, Edward Diener
> <eldiener_at_[hidden]> wrote:
>> Nonetheless macros using variadics to identify pp-lib data types on the
>> fly might still be useful and I have already come up with a pretty good
>> IS_TUPLE. Whether an IS_ARRAY, IS_LIST, or IS_SEQ is posible I shall
>> see.
>
> Useful indeed. I have implemented some sort of IS_TUPLE within
> Boost.Local. BOOST_LOCAL_PARAMS() uses it to accept both the follow
> syntaxes when variadics are present:
>
> BOOST_LOCAL_PARAMS(int x, int& y) // (1) BOOST_LOCAL_PARAMS( (int x)
> (int& y) ) // (2)
One of the things that Edward and I are discussing is introducing an
IS_VARIADIC macro along the lines of the other detection macros that
already exist (i.e. IS_NULLARY, IS_UNARY, IS_BINARY). In essence,
IS_VARIADIC detects whether its argument *begins* with a parenthesized
expression (of any arity). However, it doesn't suffer the problems
associated with try to detect emptiness. For example:
IS_VARIADIC( int x, int& y ) // 0
IS_VARIADIC( (int x)(int& y) ) // 1
IS_VARIADIC( (...) xyz ) // 1
For your particular case, wouldn't that be sufficient?
Regardless, I actually believe that the (1) case above is actually a
large step *backwards*. It's worse, not better, because it's trying (and
failing) to be the underlying language and introducing a bunch of gotchas
in the attempt.
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>. The same thing is true for these variadic macros.
> I'd prefer to see IS_TUPLE (and possibly all IS_XXX) as part of these
> Boost.Preprocess variadics changes.
Not possible unless they are laden with (unreasonable) input constraints.
Regards,
Paul Mensonides