Hi,
ich weiß, es gibt heutzutage modernere Compiler, aber trotzdem würde mich ein Phänomen interessieren, das ich bei allen DOS-Versionen von Turbo C++ und Borland C++ bis einschließlich 5.2 bemerkt habe und wollte fragen, ob man das irgendwie abstellen kann:
OK, stellt euch vor, ich habe drei Codedateien in verschiedenen Ordnern:

----------

<Projektordner>\helpers\helpers.h:

#ifndef HELPERS_H
#define HELPERS_H

// ...

#endif

----------

<Projektordner>\graphics\graphics.h:

#ifndef GRAPHICS_H
#define GRAPHICS_H

#include "../helpers/helpers.h"

#endif

----------

<Projektordner>\main.cpp:

#include "graphics/graphics.h"

int main()
{
return 0;
}

----------

Wenn ich versuche, die main.cpp zu kompilieren:

C:\MYPROJ>bcc main.cpp

gibt es folgenden Fehler:

Error graphics/graphics.h 4: Unable to open include file '../helpers/helpers.h'

Der Grund: Beim Inkludieren von Headern mit relativen Pfadangaben geht der Compiler als Startposition nicht vom Ordner aus, in dem die Datei liegt, die das #include aufruft, sondern er geht vom aktuellen Arbeitsverzeichnis aus. Das heißt, wenn die graphics.h so aussieht:

----------

#ifndef GRAPHICS_H
#define GRAPHICS_H

#include "helpers/helpers.h"

#endif

----------

dann geht's. Was natürlich völlig witzlos ist, denn wenn eine Datei inkludiert wird, ist es ja wichtig, wo die einbindende und die eingebundene Datei liegen, aber nicht, von wo aus der Compiler zufällig gerade ausgeführt wird.

Warum verhält sich der Compiler so? Ist das eine Eigenart des Borland Compilers oder hat das was mit dem damaligen C++-"Standard" zu tun? Denn während sich OpenWatcom und alte Versionen von Visual C++ durchaus korrekt verhalten, lassen sie auch die "komische" Variante durch.
Und kann man das irgendwie ändern, so dass er die Pfade richtig erkennt?