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

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

Re: Evaluation of #elif - trying again

Show key headers only | View raw

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                      ]

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