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.