min / max macros vs. std::min, and std::max
Steven S. Wolf
I dunno about any of you, but I am forever running into frustrating
cricumstances where WINDOWS.H (and it's ilk) refuse to compile because
#define min/max/MIN/MAX have been undefined, or vice versa, where I need to
use some part of the standard library and min/max/MIN/MAX muck up the
template definitions, e.g.:
class c
{
public:
c() : m_max(std::numeric_limits<double>::max()) { }
}
compiler complains that there are insufficient formal parameters for macro
max.
If I insert:
#undef max
Before my class declaration, then some other file in my build says something
stupid like error C2065: 'max' ; undeclared itentifier.
--
What in blazes is a workable method to both use std::min and std::max keep
stupid windows.h and it's ilk compiling properly?!@#$!@#$
Thanks,
Steven S. Wolf
Craig Powers
You can use _cpp_min and _cpp_max (or _MIN and _MAX), which are the
names given to std::min and std::max to avoid the collision.
Alternatively, you could do something like this:
prior to inclusion of <windows.h>,
#define NOMINMAX
prior to inclusion of whichever file it is min and max are supposed
to be in (they're actually in <xutility> which gets included by
several others),
#define _cpp_min min
#define _cpp_max max
and cross your fingers that nothing makes the mistake of using
windows::min and windows::max. If it's in your own code, it ought
to be possible to rewrite it to use std::min or std::max.
It's a bit of a hack; I use it because I have no use for the Windows
macros and I don't particularly care for the idea of using _cpp_min.
--
Craig Powers
MVP - Visual C++
Craig Powers
>
> "Steven S. Wolf" wrote:
> >
> > c() : m_max(std::numeric_limits<double>::max()) { }
>
> names given to std::min and std::max to avoid the collision.
Which has no equivalent for std::numeric_limits. Duh. (IMO, an
oversight in the library.)
Which makes this:
> prior to inclusion of <windows.h>,
> #define NOMINMAX
>
> and cross your fingers that nothing makes the mistake of using
> windows::min and windows::max. If it's in your own code, it ought
> to be possible to rewrite it to use std::min or std::max.
the only option.
Arnaud Debaene
> (Visual C++ 6 sp5)
>
> I dunno about any of you, but I am forever running into frustrating
> cricumstances where WINDOWS.H (and it's ilk) refuse to compile because
> #define min/max/MIN/MAX have been undefined, or vice versa
Halas yes! I hope the responsible for so silly macros in windows.h has been
fired! Use #define NOMINMAX before #including <windows.h>. If some code
break after that (never know), define yourself locally min and max. It's
ugly but I fear it's the only way.
Arnaud
MVP - VC
Johan Rosengren
> Halas yes! I hope the responsible for so silly macros in windows.h has
been
> fired! Use #define NOMINMAX before #including <windows.h>. If some code
> break after that (never know), define yourself locally min and max. It's
> ugly but I fear it's the only way.
>
Well, the Windows.h macro predates this newfangled C++-stuff, so I think
he/she is excused :-)
Johan Rosengren
Abstrakt Mekanik AB
> Arnaud
> MVP - VC
>
>
James Curran/MVP
news:#2XH9mBnCHA.456@TK2MSFTNGP11...
> Well, the Windows.h macro predates this newfangled C++-stuff, so I think
> he/she is excused :-)
No, they're not, because a) they should have been MIN() and MAX() instead of
min() & max() to avoid conflict with functions, and b) general purpose
functions like min & max shouldn't be in a specific purpose header like
windows.h anyway.
Johan Rosengren
"James Curran/MVP" <james...@mvps.org> wrote in message
news:eS7xppGnCHA.2412@TK2MSFTNGP09...
You're right, of course. On the other hand, a stern reprimand ought to be
enough, this long after the deed :-)
James Curran/MVP
> You're right, of course. On the other hand, a stern reprimand ought to be
> enough, this long after the deed :-)
I still vote for slapping him.