|
Boost Users : |
Subject: Re: [Boost-users] \boost\cstdint.hpp(129) : error C2059: syntax error : '::'
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2014-03-05 17:10:31
2014-03-05 22:55 GMT+01:00 Gavin Lambert <gavinl_at_[hidden]>:
> 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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net