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


Groups > comp.std.c > #6437

Re: Why doesn't __VA_LIST__ just eat the prior comma?

From Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups comp.std.c
Subject Re: Why doesn't __VA_LIST__ just eat the prior comma?
Date 2022-05-14 10:35 -0700
Organization A noiseless patient Spider
Message-ID <86a6bk3tm7.fsf@linuxsc.com> (permalink)
References <20220413165157.844@kylheku.com> <861qxta1gb.fsf@linuxsc.com> <20220419183244.563@kylheku.com>

Show all headers | View raw


Kaz Kylheku <480-992-1380@kylheku.com> writes:

> On 2022-04-19, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Kaz Kylheku <480-992-1380@kylheku.com> writes:
>>
>>> There is a well-known problem that a macro like
>>>
>>> #define foo(x, ...) something(whatever, __VA_ARGS__)
>>>
>>> cannot work when the trailing argument list is empty because
>>> you get  the expansion something(whatever, )
>>>
>>> GNU C provides ##__VA_ARGS__ which behaves like __VA_ARGS__ in
>>> the nonempty case, and eats the prior comma in the empty case.
>>>
>>> C++20 provides __VA_OPT__ which is used like __VA_OPT__(,) to
>>> conditionally eat the comma.  (GNU C has this also).
>>>
>>> The question is:  why wouldn't you just fix the semantics of
>>> __VA_ARG__ so that this is not necessary?
>>
>> This idea is considered in section "Alternative Designs" of
>>
>>     http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2160.htm
>
> Fantastic;  thanks for that link!
>
> The crux is that, for whatever reason, a macro like:
>
>       #define ADD_COMMA(...) , __VA_ARGS__
>
> is tabled as an important requirement, and for that reason, F()
> expanding to f(10), though identified as desirable, is not
> considered;  the automatic comma eating would break ADD_COMMA.
>
> But!  I think that could be acceptably handled like this:
>
>       #define FENCE
>       #define ADD_COMMA(...) , FENCE __VA_ARGS__
>
> The rule that __VA_ARGS__ consumes the comma would be carried out
> prior to the macro replacement of the token replacement sequence,
> during which time FENCE is still there.  Since FENCE doesn't look
> like a comma, all is cool.

If you feel strongly about it, write up a proposal and submit it
to the two committees.  Given that __VA_OPT__ has already been
adopted in C++20, any alternate scheme faces an uphill climb, and
so if no one feels strongly enough to try to get some other
scheme through the standardization process then it seems rather
pointless to discuss it.

Back to comp.std.c | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Why doesn't __VA_LIST__ just eat the prior comma? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-14 00:01 +0000
  Re: Why doesn't __VA_LIST__ just eat the prior comma? Ben <ben.usenet@bsb.me.uk> - 2022-04-14 14:17 +0100
    Re: Why doesn't __VA_LIST__ just eat the prior comma? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-18 16:59 +0000
      Re: Why doesn't __VA_LIST__ just eat the prior comma? Ben <ben.usenet@bsb.me.uk> - 2022-04-18 20:43 +0100
  Re: Why doesn't __VA_LIST__ just eat the prior comma? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-19 02:04 -0700
    Re: Why doesn't __VA_LIST__ just eat the prior comma? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-20 02:02 +0000
      Re: Why doesn't __VA_LIST__ just eat the prior comma? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-14 10:35 -0700

csiph-web