Groups | Search | Server Info | Keyboard shortcuts | Login | Register

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

Re: Macro replacement interpretation

Show all headers | View raw

On 03/26/2015 02:09 PM, Edward Diener wrote:
>
> Section 16.3 paragraph 4 of the C++11 standard reads:
>
> "If the identifier-list in the macro definition does not end with an
> ellipsis, the number of arguments (including those arguments consisting of
> no preprocessing tokens) in an invocation of a function-like macro shall
> equal the number of parameters in the macro definition. Otherwise, there
> shall be more arguments in the invocation than there are parameters in the
> macro definition (excluding the ...). There shall exist a ) preprocessing
> token that terminates the invocation."
>
> Does this mean that invoking a macro with more arguments than there are
> parameters in the identifier-list in the macro definition is not a
> preprocessing error ?
>
> Does this mean that invoking a macro with less arguments than there are
> parameters in the identifier-list in the macro definition is a
> preprocessing error ?
>
> My testing with the major C++ compilers on Windows and Linux, including
> gcc, clang, Intel, and Oracle but leaving out VC++ completely because its
> preprocessor is so C++ standard non-conformant, shows that error messages
> are usually produced if the number of arguments does not equal the number
> of parameters in the identifier-list, but this is not always the case (
> most notably with Oracle depending on the version ). This suggest that the
> answer to my first question is NO and the answer to my second question is
> YES. But I want to know the official answer on whether either situation
> should be considered a compiler error or whether just a warning is
> justified.

You can't get an official answer here - anyone can post their personal
opinion on the matter here, even me. An official answer requires the
filing of DR (Defect Report) with the C++ committee. Note that DRs can
be used even if you don't believe there's a defect - when used in this
fashion, they should properly be called RFIs (Request For
Interpretation), but ISO didn't bother creating a separate RFI process.

At one time, posting a message containing "Defect Report" in the
Subject: header to this newsgroup would result in someone from the
committee creating an actual defect report for you. I'm not sure whether
they're still doing that (hopefully the relevant person will respond to
this message by confirming it), but it's worth a try.

Note: I used to be an expert in C++98; I've not kept up with all of the
changes that were made in C++2003 and C++2011, but this is a rather
elementary issue by comparison. You're not likely to get a well-informed
response from this newsgroup that significantly disagrees with the
responses I gave you on this same topic in comp.lang.c++.moderated. I
won't rule out nit-picking, however.

For the benefit of those not monitoring c.l.c.m, my response was to
point out that
1. The standard does not distinguish between error messages and warning
messages, it talks only about diagnostics. The standard requires that
the method for distinguishing diagnostic messages from other messages
generated by the translation process be documented, but otherwise
imposes no constraints on the contents of those messages.

2. When a program contains at least one violation of a diagnosable rule,
at least one diagnostic message is required, but in general, the
behavior in such cases is otherwise undefined. Therefore, in particular,
the implementation is free to continue translating the program,
interpreting the rule violation in any manner it chooses.

3. I cited 1.4p8: "A conforming implementation may have extensions
(including additional library functions), provided they do not alter the
behavior of any well-formed program. Implementations are required to
diagnose programs that use such extensions that are ill-formed according
to this International Standard. Having done so, however,
they can compile and execute such programs."


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

Macro replacement interpretation Edward Diener <eldiener@tropicsoft.invalid> - 2015-03-26 12:09 -0600
  Re: Macro replacement interpretation James Kuyper <jameskuyper@verizon.net> - 2015-03-27 14:07 -0600
  Re: Macro replacement interpretation Jakob Bohm <jb-usenet@wisemo.com> - 2015-03-29 03:01 -0600
    Re: Macro replacement interpretation Francis Glassborow <francis.glassborow@btinternet.com> - 2015-03-30 12:20 -0600
    Re: Macro replacement interpretation Edward Diener <eldiener@tropicsoft.invalid> - 2015-03-30 12:21 -0600
      Re: Macro replacement interpretation Francis Glassborow <francis.glassborow@btinternet.com> - 2015-03-31 15:39 -0600
        Re: Macro replacement interpretation James Kuyper <jameskuyper@verizon.net> - 2015-04-01 16:39 -0600
      Re: Macro replacement interpretation James Kuyper <jameskuyper@verizon.net> - 2015-03-31 15:38 -0600
        Re: Macro replacement interpretation Jakob Bohm <jb-usenet@wisemo.com> - 2015-04-01 16:38 -0600
          Re: Macro replacement interpretation James Kuyper <jameskuyper@verizon.net> - 2015-04-02 13:24 -0600
            Re: Macro replacement interpretation Francis Glassborow <francis.glassborow@btinternet.com> - 2015-04-03 14:30 -0600
        Re: Macro replacement interpretation Edward Diener <eldiener@tropicsoft.invalid> - 2015-04-03 14:30 -0600
          Re: Macro replacement interpretation James Kuyper <jameskuyper@verizon.net> - 2015-04-04 15:50 -0600

csiph-web