Re: [Boost-users] Supressing GCCs 'MACRONAME' is not defined [-Wundef]

Subject: Re: [Boost-users] Supressing GCCs 'MACRONAME' is not defined [-Wundef]
From: Daniel James (daniel_at_[hidden])
Date: 2013-03-13 16:37:31

On 9 March 2013 15:23, Richard Damon <Richard_at_[hidden]> wrote:
> On 3/8/13 5:53 AM, Roman Himmes wrote:
>>
>> #define BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION 0
>> #define BOOST_MPL_HAS_XXX_NO_WRAPPED_TYPES 0
>> #define BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION 0
>> #define BOOST_MPL_HAS_XXX_NEEDS_TEMPLATE_SFINAE 0
>> #define BOOST_PP_VARIADICS_MSVC 0
>> #define BOOST_IOSTREAMS_GCC_WORKAROUND_GUARD 0
>> #define BOOST_SELECT_BY_SIZE_MAX_CASE 0
>> #define BOOST_PP_VARIADICS_MSVC 0
>> #define BOOST_FT_CC_IMPLICIT 0
>> #define BOOST_FT_CC_CDECL 0
>> #define BOOST_FT_CC_STDCALL 0
>> #define BOOST_FT_CC_PASCAL 0
>> #define BOOST_FT_CC_FASTCALL 0
>> #define BOOST_FT_CC_CLRCALL 0
>> #define BOOST_FT_CC_THISCALL 0
>> #define BOOST_FT_CC_IMPLICIT_THISCALL 0
[snip]
>>
> I suspect that you are solving a non-problem. Undefined macros in
> preprocessor statements have a defined behavior, namely they evaluate to 0

True, but we usually try to avoid these warnings, as they can be
useful. I'd suggest the original poster try opening tickets for the
relevant libraries. I don't know how responsive their maintainers will
be. I'll fix the iostreams one myself, since it's mostly unmaintained.

> If you do really want to be clean under -Wundef use code more like this
> at the end of the file:
>
> #ifundef BOOST_xxxx
> #define BOOST_xxxx 0
> #endif
>
> This will only define those macros which are undefined, so in the
> future, if config.hpp defines their value you won't get an error.

Unfortunately not. The macros are library specific macros, so when
they're defined, they're defined after config.hpp is included.