C++ Logo

liaison

Advanced search

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

From: Uecker, Martin <Martin.Uecker_at_[hidden]>
Date: Wed, 8 Feb 2023 21:04:17 +0000
Am Mittwoch, dem 08.02.2023 um 22:46 +0200 schrieb Ville Voutilainen:
> 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".

Thank you. I think I get it now: has_attribute needs
to return '1' once the compiler stops complaining
to be able to detect the *change* in behavior.

But compared to the testing for actual semantics
of an attribute, which is very useful in practice,
this seems to be a pretty weak use case.

If you really wanted to detect such a change
without bothering to look at the release notes
when upgrading, you could still always add a specific
test for this during compilation, i.e. running
a test program without feature-detect.

Martin





Received on 2023-02-08 21:04:21