Boost logo

Boost :

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

// 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__))
# else
# define BOOST_FORCEINLINE inline
# 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. 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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at