Since no one answered my previous post I will try again and rephrase
some of my question.

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 ?


--
[ 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                      ]

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.

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

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).


--
[ 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                      ]

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                      ]

Edward Diener wrote:

>  On 9/11/2011 8:47 PM, Marc wrote:
>>   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.

Indeed, I am sorry, I mis-grepped. The C++ standard has copied (looks
like verbatim to me) the relevant text of the C standard. And now that
I read it, my response sounds a bit rude.

>  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.

True. However, the wording being exactly the same, the answer should
be as well. And a link to that discussion on the C standard is
certainly relevant:
http://groups.google.com/group/comp.std.c/browse_thread/thread/252b1ad4bff8a64a/

(unofficial conclusion of that discussion: gcc's interpretation is
correct, but that's an oversight in the redaction of the C standard
which will be fixed)

That discussion also references:
https://groups.google.com/group/comp.std.c/browse_thread/thread/db2475dab8356d59/

>  I am pursuing a change on this issue in the C standard separately
>  from my pursuit of this issue in the C++ standard.

I think that if such a change is made to the C standard, it shouldn't
be hard to import it to C++.

>  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 ?

(I answered because I am interested in the outcome, and would also
welcome opinions by more experienced people)


--
[ 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                      ]

On Sep 25, 8:26 am, Edward Diener<eldie...@tropicsoft.invalid>  wrote:
>
>  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 ?

I stumbled on this recently, as I'm writing a C++ preprocessor. For
curious other readers, the corresponding comp.std.c discussion
concluded that this is also still a defect in C.

The problem is slightly broader than just expanding/interpreting
constant expressions. Since skipped directives are only processed far
enough to determine the nesting level, there is also the issue of
preprocessing tokens following #else or #endif.

Since I read somewhere that some obsolete code allows an "argument" to
#endif, I decided to ignore such a construction within a skipped group
and flag it for a peer to an interpreted group. And, for what it's
worth, I'm not evaluating the conditions of #elif directives following
an interpreted #if or #elif group.

- Hope this helps,
David Krauss


--
[ 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                      ]

On 10/12/2011 12:34 PM, David Krauss wrote:
>  On Sep 25, 8:26 am, Edward Diener<eldie...@tropicsoft.invalid>    wrote:
>>
>>    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 ?
>
>  I stumbled on this recently, as I'm writing a C++ preprocessor. For
>  curious other readers, the corresponding comp.std.c discussion
>  concluded that this is also still a defect in C.
>
>  The problem is slightly broader than just expanding/interpreting
>  constant expressions. Since skipped directives are only processed far
>  enough to determine the nesting level, there is also the issue of
>  preprocessing tokens following #else or #endif.
>
>  Since I read somewhere that some obsolete code allows an "argument" to
>  #endif, I decided to ignore such a construction within a skipped group
>  and flag it for a peer to an interpreted group. And, for what it's
>  worth, I'm not evaluating the conditions of #elif directives following
>  an interpreted #if or #elif group.

Unforunately I could never get the C++ responders on this NG to take
action for correcting the problem in C++. The best I was told was that I
had to find someone who was a member of the C++ standards committee to
take action for me and when I suggested to one responder, who may have
been a member of the C++ standards committee, that I would gladly write
up some form of document to get this corrected for C++, I received no
further response.

Both the C and C++ standard committees make it much too hard for a
discerning C/C++ programmer to effect changes in the respective standards.


--
[ 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                      ]

on Fri Oct 14 2011, Edward Diener<eldiener-AT-tropicsoft.invalid> wrote:

> On 10/12/2011 12:34 PM, David Krauss wrote:
>>  On Sep 25, 8:26 am, Edward Diener<eldie...@tropicsoft.invalid>    wrote:
>
>>>
>>>    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 ?
>>
>>  I stumbled on this recently, as I'm writing a C++ preprocessor. For
>>  curious other readers, the corresponding comp.std.c discussion
>>  concluded that this is also still a defect in C.
>>
>>  The problem is slightly broader than just expanding/interpreting
>>  constant expressions. Since skipped directives are only processed far
>>  enough to determine the nesting level, there is also the issue of
>>  preprocessing tokens following #else or #endif.
>>
>>  Since I read somewhere that some obsolete code allows an "argument" to
>>  #endif, I decided to ignore such a construction within a skipped group
>>  and flag it for a peer to an interpreted group. And, for what it's
>>  worth, I'm not evaluating the conditions of #elif directives following
>>  an interpreted #if or #elif group.
>
> Unforunately I could never get the C++ responders on this NG to take
> action for correcting the problem in C++. The best I was told was that I
> had to find someone who was a member of the C++ standards committee to
> take action for me and when I suggested to one responder, who may have
> been a member of the C++ standards committee, that I would gladly write
> up some form of document to get this corrected for C++, I received no
> further response.
>
> Both the C and C++ standard committees make it much too hard for a
> discerning C/C++ programmer to effect changes in the respective standards.

Have you tried posting a defect report here?  Presumably that should go
on the CWG issues list and at least get considered at the next meeting.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com


[ 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                      ]

On 14/10/2011 06:42, Edward Diener wrote:
>
> On 10/12/2011 12:34 PM, David Krauss wrote:
>>
>> On Sep 25, 8:26 am, Edward Diener<eldie...@tropicsoft.invalid> wrote:
>>>
>>> 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 ?
>>
>> I stumbled on this recently, as I'm writing a C++ preprocessor. For
>> curious other readers, the corresponding comp.std.c discussion
>> concluded that this is also still a defect in C.
>>
>> The problem is slightly broader than just expanding/interpreting
>> constant expressions. Since skipped directives are only processed far
>> enough to determine the nesting level, there is also the issue of
>> preprocessing tokens following #else or #endif.
>>
>> Since I read somewhere that some obsolete code allows an "argument" to
>> #endif, I decided to ignore such a construction within a skipped group
>> and flag it for a peer to an interpreted group. And, for what it's
>> worth, I'm not evaluating the conditions of #elif directives following
>> an interpreted #if or #elif group.
>
> Unforunately I could never get the C++ responders on this NG to take
> action for correcting the problem in C++. The best I was told was that I
> had to find someone who was a member of the C++ standards committee to
> take action for me and when I suggested to one responder, who may have
> been a member of the C++ standards committee, that I would gladly write
> up some form of document to get this corrected for C++, I received no
> further response.
>
> Both the C and C++ standard committees make it much too hard for a
> discerning C/C++ programmer to effect changes in the respective standards.

Actually both WG21 and WG14 (C)  go quite a long way to make
themselves accessible to the individual. ISO committees are, in
theory, composed of delegations from National Bodies and all proposals
for change should come through a National Body. Both committees in
practise do consider proposals from individuals. However both have
heavy work loads so proposals do NEED a champion who is actually
attending meetings.

Even then a large number of excellent proposals are rejected because
they have adverse effects (break legacy code, have unexpected
interactions with other proposals etc.)

That having been said, a comprehensive paper dealing with all the
issues of #elif might find a champion but this would be more likely if
it addressed the issues for both C and C++.

Strategically it might be easier to get C to change as it is the
language most interested in the pre-processor (C++ largely treats it
as a necessary evil rather than a positive benefit). If C changed C++
would almost certainly follow as WG21 usually follows C's lead on this
area.

Francis
>
>


--
[ 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                      ]

On 10/14/2011 3:02 PM, Dave Abrahams wrote:
>  on Fri Oct 14 2011, Edward Diener<eldiener-AT-tropicsoft.invalid>   wrote:
>
>>  On 10/12/2011 12:34 PM, David Krauss wrote:
>>>    On Sep 25, 8:26 am, Edward Diener<eldie...@tropicsoft.invalid>      wrote:
>>
>>>>
>>>>      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 ?
>>>
>>>    I stumbled on this recently, as I'm writing a C++ preprocessor. For
>>>    curious other readers, the corresponding comp.std.c discussion
>>>    concluded that this is also still a defect in C.
>>>
>>>    The problem is slightly broader than just expanding/interpreting
>>>    constant expressions. Since skipped directives are only processed far
>>>    enough to determine the nesting level, there is also the issue of
>>>    preprocessing tokens following #else or #endif.
>>>
>>>    Since I read somewhere that some obsolete code allows an "argument" to
>>>    #endif, I decided to ignore such a construction within a skipped group
>>>    and flag it for a peer to an interpreted group. And, for what it's
>>>    worth, I'm not evaluating the conditions of #elif directives following
>>>    an interpreted #if or #elif group.
>>
>>  Unforunately I could never get the C++ responders on this NG to take
>>  action for correcting the problem in C++. The best I was told was that I
>>  had to find someone who was a member of the C++ standards committee to
>>  take action for me and when I suggested to one responder, who may have
>>  been a member of the C++ standards committee, that I would gladly write
>>  up some form of document to get this corrected for C++, I received no
>>  further response.
>>
>>  Both the C and C++ standard committees make it much too hard for a
>>  discerning C/C++ programmer to effect changes in the respective standards.
>
>  Have you tried posting a defect report here?  Presumably that should go
>  on the CWG issues list and at least get considered at the next meeting.

I will gladly do it if you would point out to me in what form the report
should be and how I should post it here ( attachment ?, inline message ? ).

Edward Diener

[ Moderator's note: Plain text inline, please, no attachments. -sdc ]

--
[ 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                      ]