Merke: 'windows.h' hat ungewünschte Nebenwirkungen

[Kerli]

Jetzt habe ich es endlich einmal riskiert meine Spieleengine unter Windows zu kompilieren, mit dem Erfolge das ich einmal sehr, sehr komische Fehlermeldungen erhalte. Der betreffende Codeausschnitt schaut wie folgt aus:

Code: Alles auswählen

      static const Matrix4x4<T> PerspectiveLH( T width,
                                               T height,
                                               T near,
                                               T far )
      {
        std::cout << "near=" << near << "far=" << far << std::endl;
        T dist = near-far;
        if(    dist > -0.00005 || near < 0.00005
            || width < 0.00005 || height < 0.00005 )
          return Identity();

        T inv_dist = 1/dist;

        return Matrix4x4<T>(
          2*near/width, 0,             0,                    0,
          0,            2*near/height, 0,                    0,
          0,            0,             (near+far)*inv_dist, -1,
          0,            0,             2*near*far*inv_dist,  0 );
      }

Also wer hier sofort den Fehler findet muss schon sehr gut sein Irgendwann bin ich dann darauf gekommen, dass der Fehler nur dann auftritt wenn die 'windows.h' eingebunden ist. Ich brauche sie zwar selber nicht, sie wird aber indirekt über die 'SDL_opengl.h' eingebunden. Nagut, dann habe ich einfach das 'include' etwas nach hinten verschoben und es hat funktioniert.

Aber irgendwie hat es mich interessiert was jetzt wirklich schuld daran ist, und deshalb bin ich dem noch etwas genauer nachgegangen bis ich in der 'windef.h' fündig geworden bin. Dort bin ich dann auf zwei sehr sinnvolle Zeilen gestoßen:

Code: Alles auswählen

#define far
#define near

Und wer jetzt noch einmal die Parameter der Funktion anschaut, dem dürfte langsam klar werden warum das nicht gehen kann. Und das ganz nur weil Windows nicht die Altlasten ihrer 16 Bit Zeit nicht loswerden kann. Da waren 'near' und 'far' nämlich noch in Verwendung. Wer also in Gefahr läuft irgendwo eine 'windows.h' zu bekommen sollte auf jeden Fall vermeiden in irgendeiner Form 'near' und 'far' in seinem Code zu verwenden

[Dirty Oerti]

Wow, das ist gut zu wissen.
--> FAQ please

[Xin]

So gut bin ich nicht, obwohl es mir - wo man die Lösung sieht - eigentlich logisch erscheint.
Auch unter Windows 7 muss ein korrekt formuliertes Programm für Windows 1 lauffähig sein (und vermutlich auch besser lauffähig als unter Windows 1).

Seitdem ich Genesys nach Windows brachte, macht mir die Variable 'internal' auch etwas sorgen, da sie von VC++ ein Highlight erhält. Es lässt sich kompilieren, es scheint auch zu funktionieren, aber ich denke, ich werde "internal" wohl auch mal aus den Quelltexten entfernen. Es wird zwar kein C++.CLI werden, aber wer weiß, was VS 2010 melden wird...

Ich bin aber auch dafür, diesen Eintrag mit einer Überschrift, die 'near' und 'far' enthält ins C-FAQ aufzunehmen.

[Dirty Oerti]

Bleibt damit die Frage:
C-FAQ oder Windows-FAQ? Oder beides?

[Xin]

Bleibt damit die Frage:
C-FAQ oder Windows-FAQ? Oder beides?

Windows-FAQ, neuer Punkt 'WinAPI'.

[Dirty Oerti]

Ich hab einen kurzen (verbesserungsfähigen) Eintrag in windows:faq gemacht.
Außerdem den leeren Link von Kerli in c:faq auf windows:faq:winapi_near_far_defines gelenkt.

[Xin]

Ich hab einen kurzen (verbesserungsfähigen) Eintrag in windows:faq gemacht.
Außerdem den leeren Link von Kerli in c:faq auf windows:faq:winapi_near_far_defines gelenkt.

Ist der Code wirklich nicht kompilierbar??

[Dirty Oerti]

Hab ich nicht getestet, müsste aber nach dem, was Kerli beschreibt, nicht zu compilieren sein.
Die Ausdrücke near und far werden ja durch die defines ersetzt, was dzu führt, dass anstatt ihrer nichts dasteht.

[Xin]

Hab ich nicht getestet, müsste aber nach dem, was Kerli beschreibt, nicht zu compilieren sein.
Die Ausdrücke near und far werden ja durch die defines ersetzt, was dzu führt, dass anstatt ihrer nichts dasteht.

Jow... und?
Ist halt eine Funktion, die ein int erwartet - nur weil der Benutzer nichts damit anfängt, ist das doch nichts schlimmes - braucht also auch keinen Namen.

Ich habe es grade mal unter Visual Studio getestet:
Erfolgreich:

Code: Alles auswählen

int bla( int )
{
  return 0;
}

Darum auch erfolgreich:

Code: Alles auswählen

int bla( int near )
{
  return 0;
}

Aber mit Fehlermeldung:

Code: Alles auswählen

int bla( int near )
{
  near = 3;
  return 0;
}

Kurz: Du hast die einzige Variante für die Fehlerbeschreibung gefunden, die erfolgreich kompiliert


Edit: geändert.

[Dirty Oerti]

Kurz: Du hast die einzige Variante für die Fehlerbeschreibung gefunden, die erfolgreich kompiliert

Dafür sollte ich schon fast einen Preis bekommen, denke ich

Hab Plural bei den Headern eingefügt und aus der Warnung, dass es auch durch andere Header eingebunden werden kann eine eigenen Abschnitt gemacht