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