On 9/23/22 14:06, Alexander Grund via Boost wrote:
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.
__forceinline does not work in debug builds. https://godbolt.org/z/v3srxv3sr OTOH, gcc's always_inline does. https://godbolt.org/z/97rMTKv9r As I said, BOOST_FORCEINLINE is not a guarantee that the function will be inlined. It is used as an optional hint. The fact that a certain call was not inlined is not an error, meaning that it is an expected possibility, however unfortunate it is. Which means that the warning is informational at best, and completely useless most of the time. I have not had a case when I wanted to see it, nor have I heard of someone wanting it, therefore I want to disable it. Now, I see that gcc's always_inline is intended to be stronger than that. However, in practice it showed to be an acceptable alternative to __forceinline - BOOST_FORCEINLINE has been defined like that for decades, and I don't remember anyone having a problem with that. If anything, there could be a need for a new macro that triggers an error if inlining fails, which is exactly what gcc's always_inline gives. But so far there were no requests for such a macro.