问题描述
所以我在这里有点距离，我不确定确切如何进行，或者它是否可以解决...
So i am in a bit of stand off here and im not sure exactly how to go about proceeding, or if its even fixable...
我们使用另一个团队提供的第三方SDK，必须使用此SDK才能使我们的应用正常运行.
We use a 3rd party SDK provided by another team, this SDK must be used for our app to function properly.
在此SDK中，有类似这样的行
In this SDK, there are lines like this
#define uint16_t UINT16
#define uint8_t UINT8
问题出在Boost中，更具体地说，ASIO/Details/cstdint.hpp文件的行是
The issue is in Boost, more specifically the ASIO/Details/cstdint.hpp file has lines that are
using std::uint16_t
using std::uint8_t
我的应用现在无法编译，因为它确实在运行
My app wont compile now because its really doing
using std::UINT16
using std::UINT8
并且抱怨这些类型显然不在std名称空间中.
And its complaining those types do not exist in std namespace obviously.
这些UINT16和UINT8定义在非常大的应用程序中随处使用，因此替换它们不是很可行，而且即使我这样做也无法确定SDK是否会起作用.
These UINT16 and UINT8 defines are used everywhere in the app that is very large, so replacing them is not very feasible, and im not even sure if the SDK would function if i did so.
在包含boost头文件之前，我可以尝试#undef所有这些定义?然后在重新定义它们之后?似乎很愚蠢，我不知怎么怀疑它是否仍然可以正常工作.
I can try to #undef all of these defines before including the boost header files? And then redefine them after? Seems silly and i somehow doubt it would even work anyways.
有什么建议吗?
推荐答案
那倒过来了.显然，问题出在重新定义完全通用类型名称的标题中.
That's upside down. The issue is clearly in the headers that redefine perfectly common typenames.
最可行的解决方案是不先包含SDK头，再再包含任何Boost头.
The most viable solution is to not include the SDK headers before you include any boost header, ever.
一个拼凑而成的解决方法是取消定义宏. (如果您问我，那条路就是疯狂):
A patchwork workaround would be to undefine the macros. (Down that path lies madness, if you ask me):
#ifdef uint16_t
#undef uint16_t
#endif
这篇关于处理代码以重新定义int类型(uint16_t，int16_t等)，而Boost不喜欢它的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！