Re: [Boost.Config] Should BOOST_FORCEINLINE depend on NDEBUG?

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-01-29 09:44:12

On Wed, 29 Jan 2020 at 10:11, dariomt--- via Boost
<boost_at_[hidden]> wrote:
>
> Right now BOOST_FORCEINLINE does not depend on NDEBUG.

Given the current definition of the maro (copied below
https://github.com/boostorg/config/blob/develop/include/boost/config/detail/suffix.hpp#L598-L609

// BOOST_FORCEINLINE ---------------------------------------------//
// Macro to use in place of 'inline' to force a function to be inline
#if !defined(BOOST_FORCEINLINE)
#  if defined(_MSC_VER)
#    define BOOST_FORCEINLINE __forceinline
#  elif defined(__GNUC__) && __GNUC__ > 3
     // Clang also defines __GNUC__ (as 4)
#    define BOOST_FORCEINLINE inline __attribute__ ((__always_inline__))
#  else
#    define BOOST_FORCEINLINE inline
#  endif
#endif

I don't think it should as it somewhat does, implicitly, as MSVC is supposed to
ignore __forceinline in Debug builds.

> This means that on Debug builds the code asks to be forced-inlined with
> optimizations disabled, which does not make much sense to me. This is
> reflected by a myriad warnings in msvc under level 4 warnings.

https://docs.microsoft.com/en-us/cpp/cpp/inline-functions-cpp says:

"""
Even with __forceinline, the compiler cannot inline code in all
circumstances. The compiler cannot inline a function if:
    The function or its caller is compiled with /Ob0 (the default
option for debug builds).
"""

and then

"""
If the compiler cannot inline a function declared with __forceinline,
it generates a level 1 warning, except when:
    The function is compiled by using /Od or /Ob0. No inlining is
expected in these cases.
"""

So, the level 4 warning you are observing, which I guess is C4714,
is just compiler's verbose reminder of the documented circumstances.
The MSVC level 4 warnings are just *informational* warnings.
(I'd risk opinion lots/most of them are not warnings but
notices/infos, in DBMS speak :-))

IMO, Andrey's suggestion is the sensible one indeed.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net