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

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

Re: Macro replacement interpretation

Show all headers | View raw

On 3/29/2015 10:01 AM, Jakob Bohm wrote:

>
> On 26/03/2015 19:09, 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 o=
>>
> f
>
>> 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
>> th=
>>
> e
>
>> 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 ?
>>
>>
> No, the first sentence explicitly says that for a regular macro with
> a regular argument list, it is an error to pass less arguments and an
> error to pass more arguments.
>
> The second sentence explicitly says that for a varargs macro (one whose
> #define specifies an argument list ending in "...)") it is an error not
> to provide *at least* one argument for the "..." part.
>
> If that quotation is the complete specification, it seems that there is
> no syntax to define a macro accepting 0 or more parameters, and no
> syntax to name the last mandatory parameter.  Thus it might be
> cumbersome to use the standard syntax to implement
> int printf(const char *fmt, ...) as a macro that invokes
> int fprintf_private(FILE *f, const char *fmt, size_t fmtlen, ...).
>
> Now before the C and C++ committees published a (final) standard for
> how to use "..." in a macro argument list definition, many compilers
> implemented their own syntax for doing the same.  Therefore those
> compilers now have a need (at least when not running in special
> "standard C/C++ only" modes) to continue to accept their historic
> syntax for an extended period of time (e.g. 10 years after correctly
> implementing the standard syntax in a released compiler).
>
>
What is with the ten years? Any implementation can, AFAIK, an extension for
as long as its makers wish as long as they issue a diagnostic message when
such an extension is used.

Note that a compiler is, IIUC, only (an optional) part of an
implementation. An implementation can run source code via an interpreter.
That can even be just for some part of the code.

The complete tool set (including Standard libraries) is an implementation
so could we use correct terminology here (where we are dealing with the C++
Standard a degree of pedantry seems appropriate)

Now the pedants can correct my ignorance :(


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