Groups | Search | Server Info | Login | Register

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

Re: Macro replacement interpretation

Show all headers | View raw

On 04/03/2015 04:30 PM, Edward Diener wrote:
> On 3/31/2015 5:38 PM, James Kuyper wrote:
>> 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).
>
> That is fine but the meaning of your terminology "and no syntax to name
the
> last mandatory parameter" still eludes me. Are you saying that the
> paragraph in the standard should have been phrased differently ?

I'm only talking about how the standard is actually phrased; I was not
discussing any possible changes to it.
The phrase "no syntax to name the last mandatory parameter" was Jakob
Bohm's, not mine. A better way to say it is that "there is no syntax to
provide a parameter name corresponding to  the last mandatory argument".
Simplistic example:

#define macro(first_parameter, second_parameter, ...) \
     first_parameter + second_parameter + (__VA_ARGS__)

The smallest permitted number of arguments for this macro is three, so
the last mandatory argument is the third one, for which there is no
corresponding parameter name.

>>  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.
>>
>
> I was responding to the "standard syntax to implement
> int printf(const char *fmt, ...) as a macro" etc. I assume this meant
> something like:
>
> #define printf(fmt,...)

printf("Hello world!") is perfectly legal, but would violate 16.3p4 if
the macro were implemented that way. Since the macro is supposed to be a
replacement for the actual function, that makes this method of
implementing it unacceptable.

> and the suggestion that it might be cumbersome comes from the fact that a

It's not just cumbersome - it has undefined behavior when printf() is
called with a single argument.

> varying argument function does not need any arguments to be passed to the
> function for the ellipsis but that a variadic macro must have at least one
> argument passed when it specifies the variadic parameter syntax of '...'.
>
> My solution to that would be to have the variadic function be:
>
> #define printf(...) etc.

And, as indicated above, dealing with that issue produces the result
that the last mandatory argument (the format string, in this case) has
no corresponding parameter name.

>>          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.
>>
>
> I do not believe your syntax above does work, but then I am not sure what

You're correct, which was the point I was making. As I said above: "fmt
cannot be passed as the second argument of fprintf_private()". It has to
be moved to the third argument to make this work.

> the syntax of fprintf_private is supposed to be. From your previous post
> you specified it as:
>
> int fprintf_private(FILE *f, const char *fmt, size_t fmtlen, ...)

Since the format string doesn't have it's own name, it can't be
separated out from the rest of the variable arguments of the macro,
(I'm ignoring you comments about using Boost, since I'm talking
exclusively about C++, not about any additional libraries that might be
available) which means that it must immediately precede the variable
arguments in the function call. The declaration would have to be
rearranged accordingly:

int fprintf_private(FILE *f, size_t fmtlen, const char *fmt, ...);


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