Reputation: 2799
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.
Upvotes: 0
Views: 204
Reputation: 2799
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
and SetDefaultPrinterW
in the component that are just aliases for SetDefaultPrinter
. So that if windows.h renames the function, it's not a problem.
Upvotes: 0
Reputation: 308520
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.
void MySetDefaultPrinter(CNova * pNova)
{
pNova->SetDefaultPrinter();
}
Upvotes: 3
Reputation: 135413
You could use a wrapper around the external component. This is sometimes called the "Adapter" pattern.
// header file
class NovaWrapper
{
Nova *_nova;
public:
void setDefaultPrinter();
};
// implementation file - this file does not include windows.h - you need to make sure it
// does not have visibility of the "bad" SetDefaultPrinter macro
void NovaWrapper::setDefaultPrinter()
{
_nova->SetDefaultPrinter();
}
Now, modify your client code to use NovaWrapper instead of the underlying instance.
Upvotes: 1