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")