Re: [boost] [preprocessor] Warning: Incoming

Subject: Re: [boost] [preprocessor] Warning: Incoming
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-07-01 10:40:37

On Fri, Jul 1, 2011 at 2:09 AM, Paul Mensonides <pmenso57_at_[hidden]> wrote:
> 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?

Yes, in fact IS_VARIADIC is the macro Boost.Local currently uses. See
my rudimentary implementation at:
http://svn.boost.org/svn/boost/sandbox/local/boost/local/aux_/preprocessor/variadic/is.hpp

This implementation is fine for Boost.Local but I have not tested in
general and it might impose unacceptable limitation (like the empty
issue we discussed also while discussing VMD).

> 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.

I can only say that (i) I agree with you BUT (ii) my library users (my
customers) wanted (1) very badly so I really have no choice.

>> 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.

Yes, I agree that a Boost.Preprocessor version of IS_TUPLE (and also
IS_VARIADIC) should work in general and not requiring input
constraints. I did not play with Boost.Local IS_TUPLE/IS_VARIADIC
enough to assess if it is possible or not but if you guys say that a
generic IS_TUPLE is not possible that is of course a good reason not
to add it to Boost.Preprocessor.

--Lorenzo