Re: [boost] BOOST_PP_IS_*ARY questions (Re: New Borland compiler has a conforming preprocessor?)...

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-01-22 13:43:56

Hi Paul,

thanks for your detailed reply.

Paul Mensonides wrote:
>>-----Original Message-----
>>From: boost-bounces_at_[hidden] 
>>[mailto:boost-bounces_at_[hidden]] On Behalf Of Tobias Schwinger
> 
> 
>>Here are two questions regarding the BOOST_PP_IS_*ARY macros:
> 
> 
>>Is it safe to use this technique with sequences, e.g.
>>
>> [...]
> 
> Yes--with regard to what I say below.  Those macros detect "parenthetic
> expressions"--which are non-pathological (see below) sequences of preprocessing
> tokens that begin with something that's parenthesized.  E.g. these work also:
> IS_UNARY((+) -) IS_UNARY((+)(not, unary))

Non-pathological means "for every opening parentheses there's a closing one" (I
guess it applies at least to the outer nesting level)? Correct?

> 
> What compilers/preprocessors do you usually use?
> 

I'm interested in writing compiler independent portable C++ code that works in 
practice ;-)...

> 
>>And why do these components live in 'detail' (as opposed to 
>>'tuple')?  Because of Borland?
> 
> Because of Borland and others.  The problem with these macros is that they don't
> work on several supported compilers.  On others, they work, but only sometimes
> (IOW, they are unstable).  In the latter case, it isn't just a simple case of
> "if you pass it this, it doesn't work".  

Do these problems (besides the ones with BCC) apply to pathological token
sequences only?

> Rather, it is the result of
> fundamentally broken preprocessors that do things in weird orders (probably as
> some sort of optimization scheme).  The library can get away with using them
> internally because the library is doing its best to force certain things to
> happen "nearby" where they should happen--and its doing it all over the entire
> library (look at the the VC configuration, for example).  The result for client
> use is highly unpredictable because client code doesn't contain the scaffolding
> (the pp-lib bends over backward to minimize the this in user code).  

The only two places where is_*ary seem to be used are:

   list/adt.hpp
   facilities/apply.hpp

I can't see no scaffolding in the VC-case there. Am I looking in the wrong spot?

> On
> reasonably good preprocessors, this isn't a problem at all, and using them is
> perfectly safe and predictable.
> 

Would you mind listing the "reasonably good" ones (that is, if there are more on 
the list than GNU and Wave)?

> 
> Regarding your DO_UNARY-esque macros...  They would be more general if they were
> something like:
>  [...]

Sorry for picking over-generalized examples (in fact, there was no intention to
provide a general solution). They were intended to illustrate why these IS_*ARY 
macros would be a great for (very dedicated and non-generic ;-) ) user code.

I'll leave the design of generic preprocessor components to the experts (although 
I definitely feel fascinated by their implementation details).

> BTW, with variadics, you can do all kinds of fun things related to
> optional/default arguments or overloading based on number of arguments.  Some
> simple examples...
> 
> [... code]

Amazing! Of course I wouldn't ask questions about using IS_*ARY for optional 
arguments if all preprocessors would support these extensions. Until then I will 
most hopefully find the time for an in-depth study of Chaos!

BTW. are both variadic macros and overloading part of C99?

Thanks,

Tobias