Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #306

Re: Evaluation of #elif - trying again

Show all headers | View raw

On 9/11/2011 8:47 PM, Marc wrote:
>  Edward Diener wrote:
>
>>  In code such as:
>>
>>  #if SOME_MACRO(x)
>>  #elif ANOTHER_MACRO(y)
>>  #endif
>>
>>  is ANOTHER_MACRO expanded and evaluated for C++ correctness even when
>>  the result of SOME_MACRO's expansion is 1.
>>
>>  In other words what does the standard say about whether or not the C++
>>  preprocessor considers paths which are not taken in #if - #elif - #endif
>>  and #if - #else - #endif constructs and whether the code in those
>>  untaken paths need to be valid C++ or not ? By path I also mean the
>>  evaluation of #elif in the first case when the corresponding #if is not 0.
>>
>>  Is this considered to be purely a compiler decision that has nothing to
>>  do with the C++ standard or is there some C++ standard rule which says
>>  whether or not an untaken preprocessor path is parsed for valid C++ code ?
>
>  First, this is a C question. All the C++ standard says about it is: go
>  read the C standard.

This is not true. It is a C++ question and the C++ standard says no such
thing.

>
>  Second, it might be nice to provide relevant links to previous places
>  where this was discussed, like:
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320

It might be nice but it is irrelevant to what I want to know. The
decision of the gcc developers does not alter the C++ standard, and it
is the C++ standard I care about and why I am asking this here.

>
>  In C99, 6.10.0.4, we have:
>  "When in a group that is skipped (6.10.1), the directive syntax is
>  relaxed to allow any sequence of preprocessing tokens to occur between
>  the directive name and the following new-line character."
>
>  And the syntax is described above as:
>  "group:
>          group-part
>          group group-part
>  group-part:
>          if-section
>          control-line
>          text-line
>          # non-directive
>  if-section:
>          if-group elif-groupsopt else-groupopt endif-line
>  if-group:
>          # if constant-expression new-line groupopt
>          # ifdef identifier new-line groupopt
>          # ifndef identifier new-line groupopt
>  elif-groups:
>          elif-group
>          elif-groups elif-group
>  elif-group:
>          # elif constant-expression new-line groupopt
>  else-group:
>          # else new-line groupopt
>  endif-line:
>          # endif new-line
>
>  It does look like the "group that is skipped" necessarily refers to a
>  /group/  and not any /*-group/. However, the text does not explicitly
>  mention the constant-expression in the elif-group, so it doesn't sound
>  too unlikely that your interpretation is what was intended. I guess
>  you could ask for a clarification of the C standard, though I am not
>  sure how that's best done).

Having already asked for a clarification of the C standard in the
approprate NG I was told in no uncertain terms that the C standard is
not the source of the C++ standard on this issue. I am pursuing a change
on this issue in the C standard separately from my pursuit of this issue
in the C++ standard. But I have still received practically no response
regarding this issue in this NG regarding the interpretation in the C++
standard other than your reply above, which I appreciate. I still would
like some definite understanding how this is treated in C++ according to
the C++ standard.

So the question in my mind still remains: is an #elif expression
evaluated as a constant expression when its corresponding #if expression
is true ?


-- 
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Evaluation of #elif - trying again Edward Diener<eldiener@tropicsoft.invalid> - 2011-09-11 09:13 -0700
  Re: Evaluation of #elif - trying again Marc <marc.glisse@gmail.com> - 2011-09-11 17:47 -0700
    Re: Evaluation of #elif - trying again Edward Diener<eldiener@tropicsoft.invalid> - 2011-09-25 08:26 -0700
      Re: Evaluation of #elif - trying again Marc<marc.glisse@gmail.com> - 2011-09-26 09:00 -0700
      Re: Evaluation of #elif - trying again David Krauss<potswa@gmail.com> - 2011-10-12 09:34 -0700
        Re: Evaluation of #elif - trying again Edward Diener<eldiener@tropicsoft.invalid> - 2011-10-13 22:42 -0700
          Re: Evaluation of #elif - trying again Francis Glassborow <francis.glassborow@btinternet.com> - 2011-10-14 12:02 -0700
          Re: Evaluation of #elif - trying again Dave Abrahams <dave@boostpro.com> - 2011-10-14 12:02 -0700
            Re: Evaluation of #elif - trying again Edward Diener<eldiener@tropicsoft.invalid> - 2011-10-15 09:30 -0700

csiph-web