On 9 March 2013 15:23, Richard Damon
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.