Boost logo

Boost :

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:


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?



Boost list run by bdawes at, gregod at, cpdaniel at, john at