On 6/03/2014 03:13, Quoth Krzysztof Czainski:
Ok, so you have a group of external headers that do evil things like #define uint64_t. Here's what I do in cases like this.
//evil_prefix.h: // Note: this file intentionally has no include guards. #include "evil/a.h" // #defines uint64_t #if !defined(uint64_t) // these are the 3 offending lines copied from "evli/a.h": #if defined(OS_WIN) && !defined(uint64_t) #define uint64_t unsigned __int64 #endif #endif // uint64_t
//evli_suffix.h: // Note: this file intentionally has no include guards. #undef uint64_t
Armed with the above two header files, in all your files _always_ include all evil headers between the prefix and suffix includes:
#include "evil_prefix.h" #include "evil/a.h" #include "evil/b.h" ... #include "evil_suffix.h"
The suffix header makes sense, but I'm not sure what the purpose of the prefix header file is. It seems like overkill to include the offending header, repeat the offending #define, and then include the header *again*. It also doesn't really help with the OP's case. What you actually need to do, if you *really* can't modify the offending application file (which is most definitely the best option) is to make your library header defensive: SomeLibThatNeedsBoost.h: #pragma push_macro("uint64_t") #undef uint64_t // entire normal contents of the header here, including boost #include #pragma pop_macro("uint64_t") But again, it is *far* far better to remove the evil #define in the original file. Especially since cstdint will give you uint64_t anyway.