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

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

Re: Evaluation of #elif - trying again

Show all headers | View raw

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                      ]

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