3. problem mit max-Makro und max-Funktionen beim kompilieren

problem mit max-Makro und max-Funktionen beim kompilieren

  • ?

    Windows?

    #define NOMINMAX
#include <windows.h>
    0
  • M

    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?

    0
  • L

    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
    0
  • S

    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.

    0
  • M

    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

    0
  • S

    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.

    0
  • M

    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 😉

    0
  • P

    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.

    0
  • S

    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.

    0
  • M

    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 😉

    0
Anmelden zum Antworten