Re: Macro replacement interpretation

Message-ID	<RdednfuKHuOQRonInZ2dnUVZ8kednZ2d@giganews.com> (permalink)
Newsgroups	comp.std.c++
From	Jakob Bohm <jb-usenet@wisemo.com>
Subject	Re: Macro replacement interpretation
Organization	WiseMo A/S
References	<meiemi$vtj$1@dont-email.me>
Date	2015-03-29 03:01 -0600

Show all headers | View raw

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).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S=C3=B8borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[ 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