Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Francis Glassborow Newsgroups: comp.std.c++ Subject: Re: Evaluation of #elif - trying again Date: Fri, 14 Oct 2011 12:02:27 -0700 (PDT) Organization: unknown Lines: 78 Sender: std-cpp-request@vandevoorde.com Approved: james.dennett@gmail.com Message-ID: References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Trace: news.albasani.net BcCjD43cHNABRmuRHd98Y2l5UcLtVQrjLAtYCjp74BC1VE9bxvJYM54NCXG61neUAVs6ZOnb7jhPZ3KAid8N1A== NNTP-Posting-Date: Fri, 14 Oct 2011 19:02:29 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="tTm0YaAaFxeTWDYjgFmq7YC7qNJAxHDMs7vkD0RJuJ2Wm9mAljB2H/5qMm8fhQcXne1x9Kzhvj78Fh1leATk14ndbk0fdy7Z/CVnbOGdAK4qpmTJ+5FNlqaYpOdLArtA"; mail-complaints-to="abuse@albasani.net" X-Mailer: Perl5 Mail::Internet v2.05 X-Submission-Address: std-cpp-submit@vandevoorde.com Cancel-Lock: sha1:SLkPwAaUeAKTI7hxacJQWj72phk= X-Original-Date: Fri, 14 Oct 2011 09:05:28 +0100 Xref: x330-a1.tempe.blueboxinc.net comp.std.c++:324 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 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 ]