Re: [Boost-users] [signals2][variant] inline warning with MSVC 2022

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2022-09-22 13:56:29

On 9/22/22 15:57, Peter Dimov via Boost wrote:
> Frank Mori Hess wrote:
>> On Wed, Sep 21, 2022 at 12:32 PM Peter Dimov <pdimov_at_[hidden]>
>> wrote:
>>>
>>> That's not very user friendly; maybe the user _wants_ the warning in
>>> his code, and the above would disable it even if no Boost header that
>>> uses BOOST_FORCEINLINE (and generates a warning) has been included.
>>>
>>
>> Okay, then maybe BOOST_FORCEINLINE shouldn't be defined as
>> __force_inline on compilers where it doesn't actually force inlining.
> 
> That's complete nonsense. First, Microsoft invented __forceinline, so
> making BOOST_FORCEINLINE be a no-op on the very compiler for which
> the feature has been added would be ridiculous. Second, it does force
> inlining, that's why it's called __forceinline. The whole point of the warning
> is to warn about the rare cases where the compiler does not honor the
> command; it exists because people want to know whether their "force
> inline" orders are ignored.

I should add that I don't think there is *any* compiler that has a way
to 100% guarantee that a function will be inlined. So BOOST_FORCEINLINE
is a strong, but nonetheless a hint, on every compiler that provides a
suitable function attribute.