Fun-Soft - Programmierforum

Autor

Thread - Seiten: > 1 <

000
24.02.2010, 18:04 Uhr
~genzomatiker
Gast

Hi,

ich verstehe die Arbeitsweise der Direktive #include_next des C-Präprozessors nicht. Hab die Bedeutung zwar schon x-mal nachgelesen, kann mir aber das folgende Verhalten auf meinem Rechner nicht erklären:

Beim parsen des header files /usr/include/c++/4.3/cassert stolpert der CPP automatisch über folgende Direktive in Zeile 49: #include_next <assert.h>. Die einzige assert.h die auf meinem Rechner existiert liegt in /usr/include. Diese wird auch vom #include_next eingebunden. Genau das sollte laut meinem Verständniss aber unmöglich sein, da #include_next immer nach dem 2'ten Vorkommen des headers sucht und erwartungsgemäß mit "file not found" terminieren sollte.

Kann mich bitte jemand aufklären??

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

001
24.02.2010, 18:54 Uhr
0xdeadbeef
Gott
(Operator)

Wenn ich das richtig im Kopf habe, bindet #include_next die erste entsprechend benannte Datei ein, die es nach dem Durchsuchen des Verzeichnisses, in dem die Datei liegt, im Headersuchpfad findet. Hier wird wohl /usr/include/c++/4.3/ vor /usr/include durchsucht, also findet der die noch.

Ganz sicher bin ich da aber auch nicht; es handelt sich um eine gcc-spezifische Erweiterung, die eigentlich nur für die Systembibliotheken gedacht ist - für dich als Programmierer bringt sie wenig, solange du nicht in diesen herumschreiben willst.

Übrigens benutzt gcc-4.4 an dieser Stelle #include, also nehme ich an, dass #include_next hier eigentlich nicht notwendig ist. Vermutlich geht es um Szenarien, in denen Details bestimmer Systemheader in gleichnamigen Headern in compilerspezifischen Verzeichnissen stehen. Schau etwa mal in /usr/lib/gcc/$ARCH/4.3/include.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

002
25.02.2010, 09:38 Uhr
~genzomatiker
Gast

Das #include_next ist leider schon relevant für mich. Ich entwickle einen Präprozessor der unschöne Seiteneffekte des GNU-CPP nicht übernimmt. Durch den CPP verliert der Scanner Positionsinformationen beim token pasting, includes, etc.. Der Umfang meines Präprozessors darf allerdings kleiner als der des CPP sein da ich z.B. Pragmas größtenteils lesen aber nicht bearbeiten muss.

Daß gcc-4.4 das besagte Problem nicht kennt (weil kein #include_next verwendet wird) hab ich bemerkt. Ich testete meinen Präprozessor auf verschiedenen Rechnern. Einer davon läuft mit gcc-4.3 und stellte sich als der Schelm mit bösartigem Verhalten heraus.

Die korrekte Interpretation der CPP-Doku für's #include_next empfinde ich als uneindeutig. Um Unsicherheiten meinerseits auszuräumen würd ich gern den CPP-run genau beschreiben und bitte um Korrektur oder Bestätigung. Der SEARCH_PATH sieht wie folgt aus:
/usr/include/x86_64-linux-gnu
/usr/include/c++/4.3.2 <-------- [cassert]
/usr/include/c++/4.3.2/x86_64-linux-gnu
/usr/include/c++/4.3.2/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include-fixed
/usr/include <-------- [assert.h]
Die Pfadliste deckt sich auch mit der CPP-Doku und der verbose-Ausabe des CPP selbst:
`g++ /usr/include/unistd.h -v`
Nach dem das `#include_next <assert.h>` in cassert gelesen wurde, wird der SEARCH_PATH (anders als beim #include) nicht ab dem ersten Eintrag durchsucht sondern ab dem dritten. Dies ist zwar völlig unnötig (da assert.h nur 1 mal existiert) aber differiert troztdem zum Verhalten des normalen #include. Kann mir jemand sagen ob ich's endlich getickt hab?

vielen Dank im Voraus

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

003
25.02.2010, 15:11 Uhr
0xdeadbeef
Gott
(Operator)

So hab ich das jedenfalls verstanden. Wenn du aber Sicherheit willst, solltest du auf der gcc-Mailingliste nachfragen.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

004
25.02.2010, 22:37 Uhr
FloSoft
Medialer Over-Flow
(Administrator)

naja ist das nicht so?

er sucht cassert, findet es im 2ten

Code:

/usr/include/x86_64-linux-gnu
/usr/include/c++/4.3.2 <-------- [cassert]

dort steht include_next, also schau ich ab dem nächsten pfad: wo ist assert.h?

Code:

/usr/include/c++/4.3.2/x86_64-linux-gnu
/usr/include/c++/4.3.2/x86_64-linux-gnu
/usr/include/c++/4.3.2/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include-fixed
/usr/include <-------- [assert.h]

aber ansonsten wohl lieber in der mailingliste nachfragen
--
class God : public ChuckNorris { };

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

Seiten: > 1 < [ C / C++ (GNU/Linux, *NIX, *BSD und Co) ]

ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: