From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2025-05-21 14:42:15
Am 21.05.25 um 14:28 schrieb Joaquin M López Muñoz via Boost:
> El 21/05/2025 a las 13:54, Ivan Matek via Boost escribió:
>> Warning is not false positive.
>>
>>
>>> The warning does not indicate a problem in
>>> the code, and whether it is more or less readable is very
>>> subjective. It
>>> seems like a pretty pointless warning to me. Even if you care about
>>> such
>>> things, you really shouldn't be applying it to any code other than your
>>> own.
>>>
>> Well as I said it is not a problem since inline is just redundant.
>
> It is redundant from the point of view of the language standard, but
> compilers take inline as a hint to favor inlining in optimization modes.
> Consider for instance:
>
> https://godbolt.org/z/dnfhYvnMK
>
> You can see that X::foo is inlined while X::bar is not. This is the
> original
> reason why those member functions in candidate Boost.Bloom are added
> the "inline" bit, namely, to invite compilers to inline --though,
> admittedly,
> for very short functions this is hardly going to make a difference.
I think the warning is mostly correct. From the Docs:
> |inline| is redundant since constexpr functions are implicitly inlined
> |inline| is redundant since member functions defined entirely inside
a class/struct/union definition are implicitly inlined.
In your godbolt example you have *static*Â member functions.
This seems to be a difference. See https://godbolt.org/z/h76z4GfzP for
your example with static removed
I'm wondering if this is a compiler/optimizer issue that should be fixed.
So I'd say at least "inline constexpr" can be simplified, which is used
in the source.
However you are right in that clang-tidy also warns for "static inline"
where it does matter: https://godbolt.org/z/WqK3oK93Y
It seems to indeed take it as a hint as the function will be inlined
when you make it smaller.
Just my 2c,
Alex