From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-01-29 09:44:12
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
// BOOST_FORCEINLINE ---------------------------------------------//
// Macro to use in place of 'inline' to force a function to be inline
# 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__))
# define BOOST_FORCEINLINE inline
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.
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).
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.
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk