预处理器忽略
我正在从 Visual Studio 6 迁移到 Visual Studio 2008,并且我有一个正在使用的名为 SetDefaultPrinter
的组件的功能。
不幸的是现在有一个Windows库函数, SetDefaultPrinter
,具有相同的名称。 与之相关的宏妨碍了我使用我的函数。
这是我必须调用我的函数的解决方法:
#undef SetDefaultPrinter
pNova->SetDefaultPrinter();
#ifdef UNICODE
#define SetDefaultPrinter SetDefaultPrinterW
#else
#define SetDefaultPrinter SetDefaultPrinterA
#endif // !UNICODE
是否有一个不那么难看的方法来解决这个问题? 不,我无法控制该外部组件来更改函数的名称。
I am migrating from Visual Studio 6 to Visual Studio 2008 and I have a function of a component I am using named SetDefaultPrinter
.
Unfortunately there is a windows library function now, SetDefaultPrinter
, with the same name. And the macro associated with it is getting in the way of me using my function.
This is my workaround I have to call my function:
#undef SetDefaultPrinter
pNova->SetDefaultPrinter();
#ifdef UNICODE
#define SetDefaultPrinter SetDefaultPrinterW
#else
#define SetDefaultPrinter SetDefaultPrinterA
#endif // !UNICODE
Is there a less ugly way around this? And no, I do not have control over that external component to change the name of the function.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这就是C++添加命名空间的原因; 可惜 Windows 定义不能使用它们。
在另一个源模块中,您不包含 windows.h 或任何其他 Windows 包含文件,生成一个存根函数来调用您的冲突函数。
This is why C++ added namespaces; too bad the Windows definitions can't use them.
In another source module, where you do NOT include windows.h or any other Windows include files, generate a stub function to call your clashing function.
您可以在外部组件周围使用包装器。 这有时称为“适配器”模式。
现在,修改您的客户端代码以使用 NovaWrapper 而不是底层实例。
You could use a wrapper around the external component. This is sometimes called the "Adapter" pattern.
Now, modify your client code to use NovaWrapper instead of the underlying instance.
最终,通过简单地交换包含顺序就解决了这个问题。 显然,该组件的开发人员比我先意识到了这个问题,因此他们在组件中添加了
SetDefaultPrinterA
和SetDefaultPrinterW
,它们只是SetDefaultPrinter
的别名。 这样如果windows.h重命名该函数,就不是问题了。This was, in the end, fixed by simply swapping the order of includes. Apparently, the developers of this component realized the problem before me, so they included
SetDefaultPrinterA
andSetDefaultPrinterW
in the component that are just aliases forSetDefaultPrinter
. So that if windows.h renames the function, it's not a problem.