C++ Logo


Advanced search

Re: [wg14/wg21 liaison] [+externe Mail+] Re: [isocpp-core] Ignorability of attributes: draft wording, and concern about __has_c_attribute

From: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Date: Wed, 8 Feb 2023 22:46:55 +0200
On Wed, 8 Feb 2023 at 22:42, Uecker, Martin
<Martin.Uecker_at_[hidden]> wrote:
> > You have 11 compilers, and one of them will just never report "I do
> > useful things as a response to your attribute."
> > You don't care, the 10 compilers cover your needs, and the 1 remaining
> > one will be an oddball. Once you are confident
> > that the 10 compilers do the useful thing and are not going to remove
> > that functionality, and the oddball accepts
> > your code, you remove the macrodetection of the attribute. (*)
> >
> > (*) Consider [[assume]]. The 10 compilers report whether they do
> > optimizations based on assumption attributes,
> > and the one doesn't matter because it's targeting an emulator where
> > you don't run all that fast anyway. Once the
> > 10 customer-hardware-targeting compilers say "I optimize based on
> > assumptions", and the oddball says "I parse
> > assumption attributes", you no longer need to feature-detect the attribute.
> Thanks, but I am still missing something.
> If the 11 compilers accept that attribute without warning,
> I could unconditionally use the attribute without
> feature-detect. So yes, a compiler supporting the
> attribute by not emitting a warning, but not
> implementing its semantics, can sometimes be
> useful.
> But this does not depend on what we require from
> __has_c_attribute, because this is not even used.

The initial situation may be so that the oddball compiler doesn't
support the attribute without a warning.
So there's a need to detect when it stops complaining, but it might
never change to say "I accept it
and implement its recommended practice".

> A counter example would be maybe_unused. You
> might want to feature-detect it to avoid a
> warning for an unknown attribute. If a compiler
> then says it supports it but then emits
> an "unused" warning for a variable because
> actually does not, then this would be annoying.

Right, but the good part is that that's an unlikely scenario -
compilers need to do additional
work to diagnose unused variables, they don't just automatically start
doing that and then
need to do additional work to suppress it.

Received on 2023-02-08 20:47:08