<![CDATA[problem mit max-Makro und max-Funktionen beim kompilieren]]>ein Problem, dass mich schon länger ärgert. Fiel mir bei dem
MAXFLOAT-Thread
wieder ein

Bei uns kommt es hin und wieder vor, dass der Kompiler Fehler auswirft, wenn ich std::numeric_limits<int>::max() oder andere Methoden nutze, die max verwenden. Es gibt enn immer einen Konflikt. Sowas wie "::" nicht erlaubt vor MAkro max etc.
Bisher löse ich das Problem immer nur ein #undef max.
Würde aber gerne wissen, ob einer von euch weiß wo ein solches in den std-definiert wird oder wie man das Problem sonst umgehen kann.

]]>https://www.c-plusplus.net/forum/topic/190250/problem-mit-max-makro-und-max-funktionen-beim-kompilierenRSS for NodeFri, 25 Sep 2026 13:24:09 GMTTue, 21 Aug 2007 08:02:02 GMT60<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 08:03:33 GMT]]>ein Problem, dass mich schon länger ärgert. Fiel mir bei dem
MAXFLOAT-Thread
wieder ein

Bei uns kommt es hin und wieder vor, dass der Kompiler Fehler auswirft, wenn ich std::numeric_limits<int>::max() oder andere Methoden nutze, die max verwenden. Es gibt enn immer einen Konflikt. Sowas wie "::" nicht erlaubt vor MAkro max etc.
Bisher löse ich das Problem immer nur ein #undef max.
Würde aber gerne wissen, ob einer von euch weiß wo ein solches in den std-definiert wird oder wie man das Problem sonst umgehen kann.

]]>https://www.c-plusplus.net/forum/post/1348718https://www.c-plusplus.net/forum/post/1348718Tue, 21 Aug 2007 08:03:33 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 08:08:26 GMT]]>Im Standard gibt es keine Makros min/max, nur Funktionstemplates (und die Mitglieder von numeric_limits natürlich). Demnach sind die Definitionen aus Fremdbibliotheken (entweder C oder miserables C++).

C: hilft wohl nur undef vor der Verwendung der Templates.
Miserables C++: Wechsle die Fremdbibliothek 😉

]]>https://www.c-plusplus.net/forum/post/1348724https://www.c-plusplus.net/forum/post/1348724Tue, 21 Aug 2007 08:08:26 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 09:26:46 GMT]]>Windows?

#define NOMINMAX
#include <windows.h>
]]>https://www.c-plusplus.net/forum/post/1348801https://www.c-plusplus.net/forum/post/1348801Tue, 21 Aug 2007 09:26:46 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 09:42:56 GMT]]>hmmm... scheitn ein MS VS prob zu sein...
denn in windef.h findet man:

#ifndef max
 #define max(a,b)            (((a) > (b)) ? (a) : (b))
 #endif

 #ifndef min
 #define min(a,b)            (((a) < (b)) ? (a) : (b))
 #endif

mein projekt ist ein reines kosnolen-projekt.
welcher header included windef.h?

]]>https://www.c-plusplus.net/forum/post/1348823https://www.c-plusplus.net/forum/post/1348823Tue, 21 Aug 2007 09:42:56 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 09:49:26 GMT]]>windef.h wird vermutlich von windows.h includet. Der Tipp von *** war in dem Zusammenhang schon ganz gut!

Am besten Du definierst NOMINMAX global als Projekt-Define. Wenn einer von den Windows-Headern die Makros braucht, kannst Du ihnen problemlos die Templates unterschieben, indem Du sie im globalen Namensraum bekannt machst. Auf die Weise kannst Du ungehindert numeric_limits::max benutzen 😉

Beispiel:

#define NOMINMAX // am besten projektweit definieren

#include <algorithm> // für std::min/std::max

using std::min;
using std::max; // bekanntmachen der Templates im globalen NS

#include <windows.h> // wenn hier drin jetzt die Makros benutzt werden, wird in Wirklichkeit std::min/std::max benutzt
]]>https://www.c-plusplus.net/forum/post/1348831https://www.c-plusplus.net/forum/post/1348831Tue, 21 Aug 2007 09:49:26 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 10:46:32 GMT]]>LordJaxom schrieb:

windef.h wird vermutlich von windows.h includet. Der Tipp von *** war in dem Zusammenhang schon ganz gut!

Am besten Du definierst NOMINMAX global als Projekt-Define. ...

... oder gleich die windows.h rausschmeissen. Wenn es sich sowieso um eine reine KonsolenApp handelt, ist die Chance hoch, dass man ohne sie auskommt und mit Portabilität belohnt wird. 😃

Gruß,

Simon2.

]]>https://www.c-plusplus.net/forum/post/1348869https://www.c-plusplus.net/forum/post/1348869Tue, 21 Aug 2007 10:46:32 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 12:06:22 GMT]]>EDIT:
okay... windows.h wird unter windoof inkludiert...
aber mit NOMINMAX als globale Präprozessordefinition kann ich mir die undefs ersparen! danke ***** und den anderen

]]>https://www.c-plusplus.net/forum/post/1348931https://www.c-plusplus.net/forum/post/1348931Tue, 21 Aug 2007 12:06:22 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 13:51:44 GMT]]>muffmolch schrieb:

... windows.h wird unter windoof inkludiert...

von wem ? und warum ?
Ich schreibe auch Code für/unter Windows und habe die nicht inkludiert...

Gruß,

Simon2.

]]>https://www.c-plusplus.net/forum/post/1349068https://www.c-plusplus.net/forum/post/1349068Tue, 21 Aug 2007 13:51:44 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 14:03:18 GMT]]>ich brauch sie für ::Sleep(...).
und ne 3rdPartyLib für andere windows spezifische dateien...

aber dennoch plattform unabhängig durch #ifdefs

klar ich koennte hier auch #include <winbase.h> machen, aber irgendwas ist ja immer 😉

]]>https://www.c-plusplus.net/forum/post/1349075https://www.c-plusplus.net/forum/post/1349075Tue, 21 Aug 2007 14:03:18 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 14:27:47 GMT]]>Der windoof-Teil ist aber mti Sicherheit nicht Plattformunabhaengig. Vielleicht solltest du den plattformspezifischen Teil der Implementation vom Rest des Programms trennen, sprich ein Plattformunabhaengiges Interface bauen fuer die Handvoll Dinge, die Plattformspezifisch implementiert sein muessen. (wenn es mehr als ne Handvoll ist, ist es fraglich ob das dann wirklich noch plattfomrunabhaengig realisiertbar ist)
Dann bruachst du nur in der plattformspezifischen Implementation der Schnittstelle mit den #undefs etc. rumhuehnern, das eigentliche Programm wird von den Makros verschont.

]]>https://www.c-plusplus.net/forum/post/1349110https://www.c-plusplus.net/forum/post/1349110Tue, 21 Aug 2007 14:27:47 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 14:43:00 GMT]]>muffmolch schrieb:

ich brauch sie für ::Sleep(...)....

::Sleep in einem eigenen (plattformabhängigen) Modul zu kapseln wäre mir dabei sehr viel lieber, als mir dafür die komplette windows.h inkl. Rattenschwanz "reinzuziehen". Du siehst ja am "MAX", dass das schon nicht mehr standardkompatibel ist (wenn std::numeric_limits<int>::max() nicht mehr funktioniert, KANN es nicht mehr standardkonform sein) ... wer weiß, was da noch auf Dich zukommt, selbst wenn Du einen workaround für MAX hast...

Gruß,

Simon2.

]]>https://www.c-plusplus.net/forum/post/1349126https://www.c-plusplus.net/forum/post/1349126Tue, 21 Aug 2007 14:43:00 GMT<![CDATA[Reply to problem mit max-Makro und max-Funktionen beim kompilieren on Tue, 21 Aug 2007 15:18:38 GMT]]>hehe, das ist klar.
aber das projekt ist schon sehr groß > 250.000 (nur code)
und solche dinge werden aus in den dateien eingebunden in denen sie auch benötigt werden. die ::Sleep methode ist gekapselt in nem extra UbSystem-namespace. nur stand da eben derzeit schlcith udn eifnach #undef min drinnen, was mir optisch so gar nicht gefallen hat. nun steht da ein

#if defined(min) || defined(max) 
#   error add NOMINMAX to preprocessor defines
#endif

und derzeit compiliert der code problemlos unter Windows (VS > 6.0) und diversen 32/64 bit linux derivaten mit unterschieldichsten compilern (gcc>3.3, intel >8.0). ich denke, da sind wir schon auf der sicheren seite 😉

]]>https://www.c-plusplus.net/forum/post/1349148https://www.c-plusplus.net/forum/post/1349148Tue, 21 Aug 2007 15:18:38 GMT