On Sun, 26 Oct 2008 10:33:11 +0000, you wrote:
Hier liegst Du leider daneben. Beide Header Dateien werden jeweils ueber "name.h" eingebunden. Dennoch sieht der Praeprozessor nicht die lokale second.h, sondern die in ../include. Genau das ist es, was mich etwas verwirrt, da ich das nicht erwartet haette.
Hmm, der ISO-C Standard lässt an der Stelle auch zu wünschen übrig: 6.10.2 Source file inclusion [...] 2 A preprocessing directive of the form # include <h-char-sequence> new-line searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined. 3 A preprocessing directive of the form # include "q-char-sequence" new-line causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read # include <h-char-sequence> new-line with the identical contained sequence (including > characters, if any) from the original directive. letztendlich ist also das Verhalten in beiden Fällen den Compiler-Bauern überlassen. In gcc-4.3.info(Preprocessor Options) finde ich zu -I- : [...] In addition, `-I-' inhibits the use of the directory of the current file directory as the first search directory for `#include "FILE"'. Was bedeuten würde, dass gcc für mit "datei" eingebundene Header zuerst das aktuelle Verzeichnis durchsuchen sollte. Wenn er das nicht tut, wäre das IMO ein Bug. Aber ich werde nächste Woche mal unsere GCC-Spezialisten befragen, mal sehen was die dazu zu sagen haben. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org