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

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

Re: Macro replacement interpretation

Show all headers | View raw

On 3/29/2015 5: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
>

Agreed. No function-like macro can accept 0 parameters.

, and no

> syntax to name the last mandatory parameter.
>

I do not know what is meant by this. Why would one need a "name" for the
last mandatory parameter ? For any given macro the name of the last
mandatory parameter is evident.

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

If the ... might have 0 parameters then the macro is:

int printf(...)

and the first __VAR_ARGS__ parameter is the const char *fmt. The Boost PP
library has functionality to get the size of variadic data or get any
element of the variadic data.


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

Yes, reasonable.

My problem with the diagnostic message is that the message rarely says what
is the C++ standard syntax as opposed to the alternate syntax that is being
allowed as a compiler extension. Therefore the alternate syntax becomes the
C++ standard syntax for many programmers. But I understand that this is a
problem that is outside the realm of the C++ standard itself. Once the C++
standard "allowed" non-standard syntax with diagnostics to still be
standard conforming then it is up to the compilers what the diagnostic
message entails.


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