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

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-12-06 08:05:54

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?

Genny.