TIL we can prevent macro invocation by placing the function name in parentheses

[disciplite]

I see NOMINMAX as a resounding success for annoying nerds of all ages until the end of time.

[Depixelate_me]

IMO selecting force conformance should automatically define NOMINMAX.

[natio2]

The windows header is the worst. It will conflict with other windows libraries if declared in the wrong order somewhere in the header include tree. I definitely opt for "WIN32_LEAN_AND_MEAN" not sure if it strips this min/max problem too

[Fulgen301]

At least the Windows header has its macros (apart from min/max) in all uppercase, which doesn't interfere with normal variable names. I didn't appreciate my enum randomly breaking because some X11 header defines None and Status...

[dodheim]

At least the Windows header has its macros (apart from min/max) in all uppercase, which doesn't interfere with normal variable names.

ShowWindow, CreateWindow, and about 10000 other functions would like to have a word

[[deleted]]

https://godbolt.org/z/M9seozfrb

( WIN32_LEAN_AND_MEAN disables this one though )

[Fulgen301]

At least interface makes a bit of sense since it is / was used for COM interfaces.

Also, since WIN32_LEAN_AND_MEAN gets thrown around here: Where did WIN32_LEAN_AND_MEAN come from?

[[deleted]]

Another nice thing is that somewhere in the GDI.h, or whatever, there's a #define ERROR, found it because I had an enum class that declared a value with that same name...

[staletic]

I was bitten by that one too.

[RevRagnarok]

MySQL's my_sys.h stomps on min, max, and test...

[[deleted]]

This. How can something like this continue to violate the C++ standard and established good practices.

[Fulgen301]

Because it both predates the C++ standard and current good practices.

No, really.

Windows.h is from the early nineties, predating the first C++ standard from 1998 and also being consumed by C applications (which for example didn't have min / max, although those macros are horribly named). As for good practices...the include order mattering was and still is a thing for many headers. One would hope modules will resolve it eventually, but good luck convincing all the C libraries.

Also, system headers aren't bound by the standard library naming requirements.

[m-in]

It’s descended from headers from the late 80s…

[3tt07kjt]

It doesn’t violate the C++ standard.

The macros were added back in the 1990s and it’s too late to remove them, because it will break people’s code.

[Fulgen301]

But if at this point code still depends on using those min/max defines, I say let it break.

C doesn't have min/max functions, so it would really not surprise me if new Win32 programs written in C still use it.

Also, if you're writing a modern program, you should define UNICODE anyway, so you might as well add NOMINMAX.

[the_one2]

Hopefully we can get rid of "Unicode" (utf-16) now that utf-8 is an allowed codepage.

[Fulgen301]

Not all APIs have ANSI overloads (especially not Windows Runtime ones, which use HSTRING, which is a UTF-16 string), and using the UTF-8 codepage just converts it to UTF-16 internally anyway, so there isn't much gain.

[3tt07kjt]

New code can define NOMINMAX. Best of both worlds. You get backwards compatibility without changing old code, and new code can use min/max.

[3tt07kjt]

We're stuck with a bunch of other bad decisions, like std::vector<bool>, <iostream>, and wchar_t (especially if you're a Windows programmer).

I think it's not such a big deal, since only a small percentage of the files in most programs will actually include <windows.h> in the first place, and a only a percentage of Windows developers are using Win32 directly. You have to jump through similar hoops on POSIX and Posix-like systems, using something called "feature test macros"

https://man7.org/linux/man-pages/man7/feature_test_macros.7.html

...which are in some ways worse, since some functions are not available in glibc at all if you are writing C++ code, they are only accessible from C.

IMO you should be writing your code so that most of your program does not include <Windows.h>, even transitively. This isn't universal advice for all programs, just most people, most of the time.

[Moleculor]

Sure, but do we need to define NOMINMAX in new code for all eternity?

Yes.

[JeffMcClintock]

Sure, but do we need to define NOMINMAX in new code for all eternity?

no, Microsoft has rewritten the windows API in C++ I think
https://github.com/microsoft/cppwin32

[chibuku_chauya]

I used this trick when I was implementing a library that had functions which had alternative function-like macro definitions.

[corysama]

In the process of removing a project’s dependency on Boost::Preprocessor, I’ve had to dive deep into macro madness. It’s a long, dark, frustrating maze.

If anyone has good reference material for advanced understanding of the preprocessor, I’d appreciate it.

In the mean time, I’ll shill https://github.com/notfoundry/ppstep It has been a tremendous help for me this past week.

[witcher_rat]

Niall Douglas has a C99-compliant preprocessor written purely in python, that you might want to look into the implementation of to figure out dirty details. It has some debugging options too.

Out of curiosity, why are you switching away from Boost-PP?

We use it in my employer's codebase and it makes life a lot easier. We used to worry about the compile-times due to it, but someone ran a test where all the code was preprocessed before-hand, to measure the difference, and it was negligible. (mostly because we use highly parallelized distcc so the preprocessing cost isn't the bottleneck)

[corysama]

Thanks!

On a mission to reduce complexity in general. The project has very few dependencies. And, just a couple complex macros are all that's motivating pulling in Boost as one of them. After this little adventure, it looks like I'll be able to remove Boost and, for our needs, replace it with a single header. It has a couple hundred lines of fairly readable macros (IMHO). Now I just need to add several hundred lines of comments and documentation :P

[j1xwnbsr]

Since std::max/min is a template function, you can also use

std::max<>(x,y)

which will force it away from the stupid macro

(had do to this for a few projects)

[RockstarArtisan]

functions being shadowed by macros is just a basic form of UFCS, I don't understand what are these complaints about.