Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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 | Next — Previous in thread | Find similar | Unroll 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