Prevent C preprocessor to do a specific macro subsitution

Question

How can I tell the preprocessor not to replace a specific macro?

The specific problem is the following: Windows header files define the GetMessage macro.

My C++ header files with my API have a GetMessage method. I do not want to rename my method. But when using the API on Windows, including windows.h replaces my GetMessage method call with GetMessageA.

Ator

Just doing #undef GetMessage is not good, as the code that uses the API also uses the Windows GetMessage. – Ator

Ah, another example of Windows SDK's indiscriminate use of macros clobbering any and all namespaces (and not just in the namespace feature of C++). – Merchant

@vincent: see don.newfeld's comment in ShoeLace's #undef GetMessage answer – Merchant

Answer 1

have you tried just doing an

#undef GetMessage

or even

#ifdef GetMessage
#undef GetMessage
#endif

and then calling the windows GetMessageA or GetMessageW directly, whichever is appropriate.

you should know if you are using char* for wchar_t8..

(thanks don.neufeld)

Brian also says that Jus some useful info, you can also use the #pragma push_macro/pop_macro to push and pop macro definitions. This is great if you want to override a macro definition in a block of code:

#pragma push_macro("GetMessage")
#undef GetMessage

// Your GetMessage usage/definition here

#pragma pop_macro("GetMessage")

I suspect this is an MS specific feature though, so keep that in mind.

Fold

But then I can't use the Windows GetMessage anymore – Ator

Yes you can, just call GetMessageA or GetMessageW directly, whichever is appropriate. – Etna

And, yes, push_macro and pop_macro are MS specific. Pragmas are implementation-defined by definition, and I haven't noticed these outside MS code. Of course, this may not be a problem for somebody coding to the Windows API. – Bowshot

#pragma push_macro and #pragma pop_macro are supported from gcc 4.3. – Mutt

Answer 2

(GetMessage)(...)

GetMessage on MSDN

Crimea

While this would often be a good way to avoid unwittingly getting clobbered by a macro, I don't think it'll work for GetMessage, as it's not defined as a 'function-like' macro. – Merchant

Oh, right... this works only if the function is declared before the macro, not after (which I don't think is guaranteed anyway). MSN – Crimea

Answer 3

Jus some useful info, you can also use the #pragma push_macro/pop_macro to push and pop macro definitions. This is great if you want to override a macro definition in a block of code:

#pragma push_macro("GetMessage")
#undef GetMessage

// Your GetMessage usage/definition here

#pragma pop_macro("GetMessage")

I suspect this is an MS specific feature though, so keep that in mind.

Cyperaceous

MS specific shouldn't be a problem as the problem is in a macro defined by windows.h :-P – Changeup

It is a problem because there are non-MS compiler suites targeting Windows (for instance, mingw). – Citizen

Answer 4

Is there code that calls both your GetMessage and Window's GetMessage?

Such code won't be able differentiate between the two of them. You won't be able to call both in the same file.

If you use one function in one file and the other in another file, just do the suggested #undef in one file.

Exhaust

Answer 5

Given your constraints as outlined in your comment, the only way you can do this is to do a:

#undef GetMessage

right before the call to your API's GetMessage. (And this assumes noone after this point in the source file is calling the Win32 GetMessage.)

Fervency

That's not the only way, but it would require you to NOT include windows.h. :) – Coley