Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Thu, 05 Dec 2002 15:43:27 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>Hmm. Well, if it's non-conforming we probably shouldn't use it. If
>>it's just a vc bug, we could do something like
>>
>> #ifndef BOOST_STRICT_CONFIG
>> # ifdef BOOST_MSVC
>> # define BOOST_WORKAROUND(symbol, test) BOOST_DEFINED_##symbol && symbol test
>> # define BOOST_DEFINED_BOOST_MSVC BOOST_MSVC
>> # define BOOST_DEFINED_BOOST_DINKUMWARE_STDLIB BOOST_DINKUMWARE_STDLIB
>> ...
>> # else
>> # define BOOST_WORKAROUND(symbol, test) (defined(symbol) && symbol test)
>> #else
>> # define BOOST_WORKAROUND(symbol, test) 0
>> #endif
>
> The C++ standard isn't clear enough about it. It says (emphasys mine):
>
>
> Preprocessing directives of the forms
>
> # if constant-expression new-line groupopt
> # elif constant-expression new-line groupopt
>
>
> check whether the controlling constant expression evaluates to
> nonzero.
>
> 4 Prior to evaluation, macro invocations in the list of
> preprocessing tokens that will become the controlling constant
> expression are replaced (except for those macro names modified by
> the defined unary operator), just as in normal text. If the token
> defined >>is generated<< as a result of this replacement process
> or use of the defined unary operator does not match one of the two
> specified forms prior to macro replacement, the behavior is
> undefined.
>
>
> The issue is what "is generated" means. Strictly speaking, your code
> doesn't "generate" it; the token is already lexed in phase 3 and macro
> expansion just replaces the macro name with a sequence of tokens that
> contains 'defined'. A situation where it is really "generated" would
> be e.g. when it is the result of ## operator. Well, as I said the
> standard doesn't make it clear which case it refers to, however the C
> (not C++) committee recently responded to a similar issue with this:
>
>
> http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_258.htm
>
>
> It seems to me that it doesn't leave much room for doubts for C (note
> especially the suggested technical corrigendum). And since we don't
> have more precise information for C++ I think such a construct is best
> avoided. Just my opinion?
You may be right. How about this approach instead?
# include <boost/preprocessor/cat.hpp>
# define BOOST_NUMERIC_DEFINED_SUFFIX 1
# define BOOST_NUMERIC_DEFINED(x) BOOST_PP_CAT(x,BOOST_NUMERIC_DEFINED_SUFFIX)
# define SOME_COMPILER_MACRO 0 // e.g. __SUNPRO_CC
# if BOOST_NUMERIC_DEFINED(SOME_COMPILER_MACRO)
some_compiler_macro defined
# endif
# if BOOST_NUMERIC_DEFINED(SOME_OTHER_COMPILER_MACRO)
some_other_compiler_macro defined
# endif
Probably Paul M. could do better...
--
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
