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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2022-09-23 11:06:30

Am 23.09.22 um 11:59 schrieb Andrey Semashev via Boost:
> There's no middle ground behavior between inline keyword and
> BOOST_FORCEINLINE, so I don't see the reason to have yet another
> BOOST_INLINE macro. You want opportunistic inlining - use plain inline.
>
> If __pragma/_Pragma approach doesn't work, I'm inclined to shift the
> burden to library maintainers (those who are willing to deal with this)
> and users. To users: you've brought this on yourselves by using -Werror
> and -Wextra (or whatever equivalents your compiler has), so you pay the
> price by having to deal with this. Using max warnings, especially if
> promoted to errors, is useless and a bad idea.
>
> That said, I'm still in favor of an MSVC-specific fix by adding
> __pragmas to BOOST_FORCEINLINE. That pesky warning has come up a few
> times in the libraries I maintain and I never found it useful.

How can you say that there is no middle-ground between inline and 
BOOST_FORCEINLINE
but still want warnings disabled by default when the compiler
doesn't do what the macro name suggests it is told to?

The MSVC variant to what BOOST_FORCEINLINE expands to means inlining 
even with debug builds.
I think that is useful.
So sometimes you don't want to "force" inlining as the code works 
without it, but you want to strongly
encourage the compiler to do so, which is what the MSVC attribute does.
Hence the idea of a macro which does exactly that and also suppresses 
the warning when
the function isn't inlined. Currently MSVC is the only compiler to 
provide something stronger than "inline"
but other compilers may follow. And Boost.Config is the right place for 
expanding something like
BOOST_INLINE to the MSVC attribute or "inline" when that is not 
supported. This is what similar macros also do.