====== Warum man die Bezeichnungen near und far nicht verwenden sollte, wenn man die windows.h benutzt ======

Verwendet man die Header //windef.h// oder //windows.h// in seinen Programmen, dann kann man die Bezeichner //near// bzw. //NEAR// und //far// bzw. //FAR// nicht verwenden. Grund dafür sind zwei Defines "near" und "far", die in der **windef.h** enthalten sind. Heute werden diese zwar nicht mehr verwendet, sind aber aus Kompatibilität zu Programmen aus der Zeit des 16-Bit Windows, als es noch near- und far-Zeiger gegeben hat, noch immer vorhanden.

===== Fehlermeldung =====

Wenn man nun irgendwo in seinem Programm eine Variante der erwähnten Bezeichner verwendet kann es zu Fehlermeldungen ähnlich dieser kommen:

  <file>:<line>: error: expected primary-expression before '...' token


Jetzt schaut man sich dann seinen Code an und findet aber offensichtlich keinen Fehler. Dann sollten wir uns einfach einmal alle 'near' und 'far' wegdenken und den Code noch einmal anschauen.

===== Beispiel =====

Schauen wir uns jetzt noch ein paar Beispiel an, die teilweise nicht einmal einen Compilerfehler hervorrufen, sondern einfach nur anders als erwartet funktionieren:

<code c>
#include <windows.h>

// Folgende Funktion lässt sich kompilieren, gibt aber grundsätzlich den Wert -1 zurück.
int do_something (int near)
{
  //Tut etwas
  return near - 1;
}

// der Compiler sieht nur noch " * = 0;" und gibt eine Fehlermeldung
void  do_more (char *far)
{
  //Tut noch mehr

  *far = 0;
}
</code>


Der obige Code wird nicht kompilierbar sein, da die Bezeichner "near" und "far" durch die Defines, welche in der **windef.h** enthalten sind entfernt werden:

<code c>
#define far
#define near
</code>

===== Achtung - Fehler auf Umwegen =====

**windef.h** wird auch über die häufig verwendete //windows.h// eingebunden. Allerdings kann man auch Opfer werden, wenn man keine der beiden Dateien selbst einbindet. Wenn man zum Beispiel die SDL unter Windows verwendet und dabei //SDL_opengl.h// einbindet wird die //windows.h// und damit in weiterer Folge wieder auch die **windef.h** eingebunden. Es ist also ratsam, entweder sehr genau zu überprüfen, ob die **windef.h** eingebunden wird oder am Besten gleich auf die Verwendung von 'near' und 'far' zu verzichten.