Präprozessor und #include ignorieren

Bashar

Klaus82 schrieb:

Ich dachte das mit den include guards funktioniert so:

foo.cpp wird kompiliert. Dabei existiert noch kein FOO_H_ , d.h. zum Einen wird dieses Symbol (diese Variable?) angelegt und anschließend alles includiert.

main.cpp wird kompiliert. Es fügt foo.h und check, ob FOO_H_ bereits existiert - jap, tut es.

Nein, tut es nicht.

Schau dir nochmal an, wie der Präprozessor funktioniert. Du kannst beim gcc auch mit gcc -E den Code nach dem Präprozessor ausgeben lassen, das ist vielleicht mal ganz interessant.

Klaus82

SG1 schrieb:

main.cpp wird kompiliert. Es fügt foo.h und check, ob FOO_H_ bereits existiert - jap, tut es.

Falsch. Neue Übersetzungseinheit (neue .cpp-Datei), also sind auch alle Präprozessorsymbole weg.

Hä?

Ich dachte diese include guards sollen helfen, falls eine Datei in verschiedene Dateien öfter eingebunden wird. Falls diese Präprozessorsymbole aber bei jeder dieser verschiedenen Dateien wieder verworfen werden, wie kann die include guard dann helfen?

Ich dachte das sei genau dafür gedacht, dass ich nicht noch einmal alles neu einbauen musse, wenn es bereits (wie z.B. im Falle von foo.h ) geschehen ist. Aber das ist gerade nicht der Fall? ?

Gruß,
Klaus.

SG1

Include Guards sollen verhindern, dass ein Header innerhalb einer Übersetzungseinheit mehrfach eingebunden wird (z.B. indirekt über andere Header).

Ethon

Include Guards herlfen nur dagegen:

#include "foo"
#include "foo"

Der Include Guard fängt das zweite Include ab und verhindert damit Compilerfehler.
In der echten Welt ist es natürlich eher so dass du a und b inkludierst die zufälligerweise beide c inkludieren. Ohne Include Guard hättest du 2x c eingebunden.

Klaus82

Bashar schrieb:

Schau dir nochmal an, wie der Präprozessor funktioniert. Du kannst beim gcc auch mit gcc -E den Code nach dem Präprozessor ausgeben lassen, das ist vielleicht mal ganz interessant.

Boa, was ist das denn? Ein simples hello world Programm liefert bei der -E Option eine Ausgabe von ~17.000 Zeilen.
Ich sehe schon, ich wieder viel zu lernen habe ...

Aber was ist jetzt der richtige Ansatzpunkt, um weiter zu machen?

Gruß,
Klaus.

Bashar

Klaus82 schrieb:

Aber was ist jetzt der richtige Ansatzpunkt, um weiter zu machen?

Du meinst abgesehen davon, endlich mal zu verstehen, was der Präprozessor macht? In main.cpp das includieren, was du dort brauchst.

Klaus82 schrieb:

Aber was ist jetzt der richtige Ansatzpunkt, um weiter zu machen?

Wenn boost nur in foo.cpp verwendet wird, gehört die Includeanweisung auch dahin und nicht in den Header.

Übersetzt du jede Datei einzeln per Compileraufruf? Includepfade werden normalerweise im Makefile oder dem "Projekt" der IDE global gesetzt => das Problem existiert nicht mehr.

Klaus82

manni66 schrieb:

Übersetzt du jede Datei einzeln per Compileraufruf?

Ich dachte das ist der Vorteil bzw. Gedanke von Objektorientiert programmieren?

Ich bastle eine Klasse und teile die Deklaration und Implementierung auf header und cpp Datei auf. Dann kompiliere ich die cpp Datei.

Ich muss meinem Kollegen also lediglich sagen, wie er die src file zu kompilieren hat, z.B. boost Verzeichnis includieren und wie die Memberfunctions aufgerufen werden.

Wenn mein Kollege aber jetzt in jeder Datei, die meine Klasse verwendet, wiederholt z.B. boost includieren muss, dann wird er sich zu recht aufregen.

Oder ist das kein Inhalt von OOP, sondern Präprozessor bzw. Compiler?

Gruß,
Klaus.

Klaus82 schrieb:

manni66 schrieb:

Übersetzt du jede Datei einzeln per Compileraufruf?

Ich dachte das ist der Vorteil bzw. Gedanke von Objektorientiert programmieren?

Nein

Klaus82

Okay.

Dann stelle ich die zu durchsuchenden Pfade einfach global ein und die Sache hat sich erledigt.

Viele Grüße,
-- Klaus.