From: David Abrahams (dave_at_[hidden])
Date: 2002-12-08 18:20:27
Gennaro Prota <gennaro_prota_at_[hidden]> writes:
> On Sun, 08 Dec 2002 15:45:39 -0500, David Abrahams
> <dave_at_[hidden]> wrote:
>>Gennaro Prota <gennaro_prota_at_[hidden]> writes:
>>> Well, there's no problem with __SUNPRO_CCBOOST_NUMERIC_DEFINED_SUFFIX, just
>>> with __SUNPRO_CC1.
>>We seem to be talking past one another. I've been trying to tell you
>>that preventing expansion into __SUNPRO_CC1 was the very reason I used
> Ah! Are you saying you think BOOST_NUMERIC_DEFINED_SUFFIX may remain
> unexpanded? Indeed, as far as I understand the preprocessing, it
> always becomes 1.
I guess you're right.
> Let me explain again what I meant: the reason why your example doesn't
> trigger the #error is that you define SOME_COMPILER_MACRO1 to zero
> (and because of the test ">0"). Actually, you "fall" into using
> SOME_COMPILER_MACRO1 but, luckily, the whole test yields false
> anyway. To have an unexpected #error I suggested you to try:
> The precondition is that the first argument of BOOST_WORKAROUND must
> be either undefined or expand to something, i.e. you can't use for
> instance this
> #define X
> so I don't see any macro invocation where there's an empty sequence of
> tokens used as argument. Do you?
No. I happily acknowledge your superior strength with the macro
preprocessor. Would you kindly post what you think the correct form
of BOOST_WORKAROUND should be?
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk