别人的库#define命名冲突

2021-12-19 00:00:00 opengl sdl c++

很难为这个问题想出一个合适的标题.总之...

Hard to come up with a proper title for this problem. Anyway...

我目前正在为 GUI://www.libsdl.org" rel="noreferrer">SDL.当一个奇怪的错误出现时，我已经完成了软件绘图并且正在开始它的 OpenGL 部分.我包含了SDL/SDL_opengl.h"头文件并编译.它抛出错误 C2039: 'DrawTextW' : is not a member of 'GameLib::FontHandler'"，这是一个足够简单的错误，但我没有任何名为 DrawTextW 的东西，只有 FontHandler::DrawText.我搜索 DrawTextW 并在标题WinUser.h"中的 #define 调用中找到它！

I'm currently working on a GUI for my games in SDL. I've finished the software drawing and was on my way to start on the OpenGL part of it when a weird error came up. I included the "SDL/SDL_opengl.h" header and compile. It throws "error C2039: 'DrawTextW' : is not a member of 'GameLib::FontHandler'", which is a simple enough error, but I don't have anything called DrawTextW, only FontHandler::DrawText. I search for DrawTextW and find it in a #define call in the header "WinUser.h"!

//WinUser.h
#define DrawText DrawTextW

显然它用 DrawTextW 替换了我的 DrawText！我怎样才能阻止它像那样溢出到我的代码中?

更改我自己的函数名称是一件小事，但像这样的命名冲突似乎很危险，我真的很想知道如何一起避免它们.

It's a minor thing changing my own function's name, but naming conflicts like this seem pretty dangerous and I would really like to know how to avoid them all together.

干杯！

推荐答案

你有几个选择，但都糟糕透了.

You have a couple of options, all of which suck.

  • 在您自己的代码中添加#undef DrawText
  • 不要包含 windows.h.如果另一个库为您包含它，请不要直接包含它.而是将其包含在单独的 .cpp 文件中，然后该文件可以在其标头中公开您自己的包装函数.
  • 重命名您自己的DrawText.
  • Add #undef DrawText in your own code
  • Don't include windows.h. If another library includes it for you, don't include that directly. Instead, include it in a separate .cpp file, which can then expose your own wrapper functions in its header.
  • Rename your own DrawText.

如果可能，我通常会选择中间选项.windows.h 在无数其他方面表现不佳(例如，除非您启用 Microsoft 的专有 C++ 扩展，否则它实际上不会编译)，所以我只是像躲避瘟疫一样避免它.如果我可以提供帮助，它不会包含在我的文件中.相反，我编写了一个单独的 .cpp 文件来包含它并公开我需要的功能.

When possible, I usually go for the middle option. windows.h behaves badly in countless other ways (for example, it doesn't actually compile unless you enable Microsoft's proprietary C++ extensions), so I simply avoid it like the plague. It doesn't get included in my files if I can help it. Instead, I write a separate .cpp file to contain it and expose the functionality I need.

此外，请随时将其作为错误和/或反馈提交到 connect.microsoft.com.Windows.h 是一个设计得很糟糕的标题，如果人们引起 Microsoft 的注意，那么他们有朝一日可能会修复它.

Also, feel free to submit it as a bug and/or feedback on connect.microsoft.com. Windows.h is a criminally badly designed header, and if people draw Microsoft's attention to it, there's a (slim) chance that they might one day fix it.

好消息是windows.h 是唯一 表现如此糟糕的头文件.其他标头通常会尝试在其宏前添加一些特定于库的名称以避免名称冲突，它们会尝试避免为通用名称创建宏，并且会尝试避免使用不必要的宏.

The good news is that windows.h is the only header that behaves this badly. Other headers generally try to prefix their macros with some library-specific name to avoid name collisions, they try to avoid creating macros for common names, and they try avoid using more macros than necessary.

相关文章