On Wed, 29 Jan 2020 at 10:11, dariomt--- via Boost
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/... // 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