\boost\cstdint.hpp(129) : error C2059: syntax error : '::'
I am trying use boost in my application. I am getting compiler error, if I try to include headers after one of the application include file where uint64_t is defined. #if defined(OS_WIN) && !defined(uint64_t) #define uint64_t unsigned __int64 #endif Error: Can some one help me find the better solution to resolve these type of issues? Regards, UJ
2014-03-05 12:11 GMT+01:00 Uthpal Urubail <uthpal.urubail@altair.com>:
I am trying use boost in my application. I am getting compiler error, if I try to include headers after one of the application include file where uint64_t is defined.
#if defined(OS_WIN) && !defined(uint64_t) #define uint64_t unsigned __int64 #endif
Error:
[...]
Can some one help me find the better solution to resolve these type of issues?
Regards, UJ
Hi Uthpal, Are you allowed to modify the application file? It is generally a bad idea to #define identifiers, that can likely be used in other header files. So, the preferred solution is to modify that application header. Instead of: #define uint64_t unsigned __int64 try: typedef unsigned __int64 uint64_t; Or better yet, just use #include <stdint.h> or <cstdint> if they are available, because they provide the typedef uint64_t and alike. On the other hand, if you are not allowed to modify the offending application file, then you'll need some trickery to work around this. I can elaborate on this if you need it. HTH, Kris
Thanks a lot Kris. I am not allowed to modify application file. Can you help me with the workaround? Regards, UJ
2014-03-05 14:21 GMT+01:00 Uthpal Urubail <uthpal.urubail@altair.com>:
Thanks a lot Kris. I am not allowed to modify application file. Can you help me with the workaround? Regards, UJ
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" If you follow the above rule, you can then include your files anywhere in any order, and nothing should explode any more. Regards, Kris
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.
2014-03-05 22:55 GMT+01:00 Gavin Lambert <gavinl@compacsort.com>:
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")
Here's an example: // my_file1.h: #include "evil_prefix.h" #include "evil/a.h" #include "evil_suffix.h" // my_file2.h: #include "evil_prefix.h" #include "evil/b.h" // #includes "evil/a.h" #include "evil_suffix.h" // my_file3.h: #include "my_file1.h" #include "my_file2.h" Without "evil_prefix.h" "evel/b.h" would have uint64_t undefined, while it may rely on it being defined. Regards, Kris
participants (4)
-
Gavin Lambert -
Krzysztof Czainski -
Uthpal Urubail