Groups | Search | Server Info | Login | Register

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

Re: Macro replacement interpretation

Show all headers | View raw

On 03/30/2015 02:21 PM, Edward Diener wrote:
>
> 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:
...
>>> equal the number of parameters in the macro definition. Otherwise, there
>>> shall be more arguments in the invocation than there are parameters in
>>> th=
...
>> 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.
>>
>
> 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.

"Otherwise, there shall be more arguments in the invocation than there
are parameters in the macro definition." In this context, "otherwise
refers to function-like macros with "..." in the parameter list. Note
the "shall" - the behavior is undefined unless there is at least one
argument that has no corresponding named parameter. That first extra
argument is therefore mandatory (at least, if you wish to avoid
undefined behavior); it is also the last mandatory argument (at least as
far as C is concerned - the expansion of the function-like macro itself
may impose additional requirements).

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

I'm not sure what the above is supposed to be. You call it a macro, yet
there's an 'int' rather than a #define at the front, which makes it
appear to be a declaration. The declaration for printf is

        int printf(const char * restrict format, ...);

In order for printf() to be defined as macro that calls
fprintf_private() while allowing it be called with only a format string
(as is legal), it would have to look something like this:

// Remove any pre-existing #define of printf() by the implementation.
#undef printf
#define printf(...) fprintf_private(stdout, \\
        count_va_args(#__VA_ARGS__), __VA_ARGS__)

If it weren't done that way, printf("Hello World!") would violate
16.3p4, so fmt cannot be passed as the second argument of
fprintf_private(), as originally specified by Jakob Bohm. It would have
to be passed along with the variable part of the argument list.


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