Re: [boost] SunPro CC and preprocessor lib.

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-10-31 21:34:05

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>

> Hi Paul,
>
> It appears that the Sun compiler has some preprocessor bugs, though I
> can't tell exactly what they are. It appears that using
> BOOST_PP_CONFIG_BCC makes it happy. However, I don't have the
> expertise to probe the preprocessor and produce minimal bug reports
> for Sun. Can you suggest some tests for me to throw at it?

Hi Dave,

Okay, the problem with Borland's preprocessor (and this is the only one that
I've found) is that it assumes more than it should.  In particular, it
assumes that nothing can come after the name of a macro except operators
(such as comma) or a parenthesized argument list.  For example,

#define test(macro) macro xyz
#define binary(x, y) ...
test(binary)

What this *should* expand to is:

binary xyz

However, Borland assumes that text cannot follow, so it concatenates:

binaryxyz

This interferes with detection macros (i.e. undocumented
BOOST_PP_IS_NULLARY, BOOST_PP_IS_UNARY, BOOST_PP_IS_BINARY, etc.) causing
them to not work correctly.  These macros are *not* part of the PP lib's
interface, so don't use them!  Basically, they detect whether something is
parenthesized or not, but they only work with for the corresponding arity:

BOOST_PP_IS_NULLARY( 123 ) // 0
BOOST_PP_IS_NULLARY( ()  ) // 1
BOOST_PP_IS_NULLARY( (1, 2) ) // error

...etc.

All these macros do is put a nullary, unary, or binary macro in front of the
argument and check if it expands.  Of course, when it does that Borland will
concatenate the macro name to the argument (e.g. 123 above) which will
produce CHECK123 instead of CHECK 123.

The Borland mode of the PP lib avoids using these macros, and instead uses
undefined behavior that produces the correct result.

This bug is not present in Borlands command line tool preprocessor.
However, it seems to also be present in IBM's preprocessor.  Maybe Sun's has
the same problem.  This is the *only* thing the Borland configuration works
around, so it is a pretty safe bet that this is the problem.

To reiterate:

#define TEST(macro) macro 123
#define ABC(x, y) ...

TEST( ABC )

..should expand to:

ABC 123

not:  ABC123
and definitely not:  ...123

Incidentally, if speed was not such a major issue, and I could get the
detection macros above to work with these preprocessors, I could
*drastically* reduce the number of macros that are defined by the PP lib--I
can think of *at least* a thousand off the top of my head. :(

I'm thinking about doing an *absolutely* strict version of the PP lib that
uses no hacks at all.  In effect, it would be a good judge of compliance
(and speed), and give me a clean base from which I can produce the hacked
versions.  This is not my immediate concern however....

Paul Mensonides