C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] labels

From: Niall Douglas <s_sourceforge_at_[hidden]>
Date: Wed, 12 Aug 2020 12:52:40 +0100
On 11/08/2020 12:04, Uecker, Martin wrote:
> Am Dienstag, den 11.08.2020, 10:09 +0100 schrieb Niall Douglas via Liaison:
>> On 11/08/2020 07:37, Uecker, Martin via Liaison wrote:
>>
>>> I recently proposed changes to the C grammar which got
>>> voted into C2X by WG14 (N2508, also see N2496).
>>>
>>> This allows placing of labels everywhere in a compound
>>> statement, even before declarations and at the end
>>> of a block, which was not possible in C so far.
>>
>> Long overdue! And thank you for the work to fix this.

I'd like to reemphasise that Martin's changes have improved the
compatibility story overall. He just went a bit further again.

>>> It has been pointed out to me that while C++ allows
>>> labels before declarations, it does not allow them
>>> at the end of a compound statement.
>>>
>>> I plan to propose a change to C++ to make this
>>> possible too and I wonder if you have any comments
>>> or suggestions related to this?
>>
>> My first reaction is simply "just insert a ;". Perhaps that won't be a
>> common reaction.
>
> Well, this is was what some also said about labels before
> declarations...
>
> So you would not need to see a use for this in C++?

It turns out that my first reaction was indeed the common reaction. Good
to learn.

Let's see if I'm still on the button then: I really don't feel strongly
one way or another on labels at the end of a compound statement. If C
allows them, I'm minded that so should C++, because I care more about
better compatibility than whether it's a good idea or not on this
particular topic.

I am a very rare user of goto, but I do write a few of them per year
where in my judgement they are the least worst construct available. If
we gained computed goto, I might use them more, but equally C++ has much
better, more efficient and link-time deindirectable, alternatives.

That said, I'm not one to turn down a new tool in the toolbox. And it
has always puzzled me why switch...case is so fixed function, and I
can't take manual control over it (to be specific, I have had hot loops
where the compiler's choice of switch...case implementation was a severe
performance penality, and replacing it with a "Niall knows better"
implementation quadrupled performance. Right now enforcing a manual
implementation is hassle and inconvenient and introduces maintenance
burden, and I'd like that whole story to be better)

Niall

Received on 2020-08-12 06:56:06