ansaurus

Question

Answer 1

A:

Yep, I've meet the same problem. I found only one solution:

#ifdef min
#undef min
#endif //min

Place it right after includes have done.

Dewfy 2009-09-08 13:48:28

Answer 2

+9 A:

The only really general solution is to not include windows.h in your headers.

That header is a killer, and does pretty much anything it can to make your code blow up. It won't compile without MSVC language extensions enabled, and it is the worst example of macro abuse I've ever seen.

Include it in a single .cpp file, and then expose wrappers in a header, which the rest of your code can use. If windows.h isn't visible, it can't conflict with your names.

For the min/max case specifically, you can #define NOMINMAX before including windows.h. It will then not define those specific macros.

jalf 2009-09-08 14:00:51

Voted up, as we came to the same conclusion here. Among other evils, it adds about 19K *per object file*. We just created our own header file with the few things we typically need from windows.h in it.

T.E.D. 2009-09-08 14:07:38

Good answer. Didn't know about that `NOMINMAX` trickery.

Johannes Schaub - litb 2009-09-08 14:50:12

Well, it's a typical Microsoft solution... "Our macros are causing trouble? Well, we'll just add a macro to disable them!" ;)

jalf 2009-09-08 15:08:48

@jalf Actually, windows.h was implemented a looong time ago, well before std::min (or any other standard min/max) was created. Changing windows.h by removing their min/max would have broken way too much code. Microsoft (nearly) always errs on the side of caution there: if you don't need min/max, you can tell it NOMINMAX. (This does not address the original problem where they defined a macro with non-capital letters.)

mos 2009-09-08 15:17:12

@mos: I know, but as you point out, the root problem is that they gave the macros ridiculously bad names *to begin with*. And what's worse is that they then decided to create hundreds of *new* badly named macros when they added unicode support. They obviously hadn't learned anything from min/max.

jalf 2009-09-08 15:50:01

Replacing macro `min` in windows.h with std::min will make Windows work faster ;) `min` macro computes minimum value twice. Same for `max` macro.

Kirill V. Lyadvinsky 2009-09-08 15:53:35

Thank you for your kind concern, however I would like to make it without undefining the macros. litb's solution is worked.

msh 2009-09-09 05:42:47

This doesn't undefine the macro. It tells Windows not to define it in the first place. :)

jalf 2009-12-03 12:50:45

Answer 3

A:

In addition to jalf's answer, you could also #define WINDOWS_LEAN_AND_MEAN before including windows.h. It will get rid off min, max and some more noise from windows headers.

sbk 2009-09-08 14:34:07

Thank you. However in my project, that make much more headache.

msh 2009-09-09 05:45:29

Answer 4

A:

Dewfy, The problem with that solution is if you nee to use the macro afteryards.

I even tried the defining NOMINMAX but it didn't work.

The best solution i found was the one from Johannes Schaub: (std::numeric_limits::min)()

eniac 2010-02-04 13:32:45

ansaurus

tags:

views:

answers:

macro and member function conflict

related questions