Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Sun, 08 Dec 2002 15:45:39 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>Gennaro Prota <[EMAIL PROTECTED]> 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
>>BOOST_NUMERIC_DEFINED_SUFFIX.
>
> 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
"un"-----------------------^
> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
