Re: [boost] Re: [Config] Testing instructions for compiler vendors

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-06 09:05:38

Gennaro Prota <gennaro_prota_at_[hidden]> writes:

> On Thu, 05 Dec 2002 15:43:27 -0500, David Abrahams
> <dave_at_[hidden]> 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
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution