proggen.org

Verfasst: **Do Okt 01, 2009 10:59 pm**

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

Verfasst: **Do Okt 01, 2009 11:02 pm**

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

Verfasst: **Fr Okt 02, 2009 9:23 am**

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.

Verfasst: **Fr Okt 02, 2009 12:54 pm**

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

Verfasst: **Fr Okt 02, 2009 1:18 pm**

Dirty Oerti hat geschrieben:Bleibt damit die Frage:
C-FAQ oder Windows-FAQ? Oder beides?

Windows-FAQ, neuer Punkt 'WinAPI'.

Verfasst: **Fr Okt 02, 2009 2:06 pm**

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.

Verfasst: **Fr Okt 02, 2009 2:18 pm**

Dirty Oerti hat geschrieben: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??

Verfasst: **Fr Okt 02, 2009 2:20 pm**

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.

Verfasst: **Fr Okt 02, 2009 3:01 pm**

Dirty Oerti hat geschrieben: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.

Verfasst: **Fr Okt 02, 2009 3:34 pm**

Xin hat geschrieben: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

proggen.org

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

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

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

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

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

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

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

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

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

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

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