Re: [Bloom] Some questions

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