Frage zu dieser Klausurbewertung

Artchi

Welche Komplikationen? Durch die Include-Guards wird verhindert das ein Header in einer Compile-Einheit mehrmals inkludiert wird. Ich kann, wenn ich will, 10x hintereinander <string> inkludieren, das stört heute nicht und auch in Zukunft nicht. Es kann in riesigen Projekten lediglich zu unnötigen Compile-Zeiten kommen, aber das muß sich dann wirklich summieren.

Für mich ist das nur ein Schönheitsfehler, aber es ist kein technischer Fehler. Soll der Prof halt ein Sternchen/Smily weniger am Seitenrand dran machen. Nen Punktabzug der ein "Falsch" gleichwertig ist, würde ich nicht sehen.

Zeig uns doch mal was falsch ist.

CStoll

Randfrage: Um was für einen Header ging es denn eigentlich, den du doppelt eingebunden hast?

Bei gut geschriebenen Headern dürfte es eigentlich keine Probleme geben, wenn sie mehrfach im Projekt verwendet werden. Schwierig wird es nur, wenn der Autor keine Include Guards gesetzt hat (dann beschwert sich der Compiler evt über mehrfache Definitionen) oder intelligenterweise seine Funktionen direkt im Header definiert hat (das wird dir der Linker um die Ohren hauen)^*.

Was den Wartungsaufwand angeht: Einen Header solltest du überall dort einbinden, wo du ihn brauchst. Dann mußt du dich nicht darauf verlassen, daß jemand anderes das für dich erledigt.

^* Direkt im Header solltest du nur Templates und explizite inline-Funktionen definieren, weil der Compiler für die Template-Auflösung bzw. inline-Ersetzung den Quellcode der Funktion benötigt - aber in beiden Fällen wird das Ergebnis auch vom Linker geschluckt.

danke für die Antworten.

die Aufgabenstellung habe ich leider nicht.

Ihr könnt euch das so vorstellen - ich glaube das waren auch die Namen der Dateien:
a.h, b.h., c.h., d.h

a.cpp, b.cpp, c.cpp, d.dpp, main.cpp

nachbilden kann ich die Aufgabe aus dem Kopf leider nicht. Jedenfalls mussten halt die (bzw. einige) headerdateien mit includes versehen werden und in die entspr. Sourcedateien noch eingetragen werden. Natürlich aufgrund der verwendeten Funktionen, Strukturen, Variablen.

Und anstatt b.h in b.cpp zu setzen, habe ich b.h in a.h gesetzt und a.h in b.cpp. Das andere kam mir zu einfach vor

ich hoffe, dass dies übersichtlich genug ist

CStoll

DanielPort schrieb:

Und anstatt b.h in b.cpp zu setzen, habe ich b.h in a.h gesetzt und a.h in b.cpp. Das andere kam mir zu einfach vor

Ja, das könnte Probleme erzeugen. Du verlässt dich darauf, daß andere dir deinen Header mitliefern - und wenn der Autor von a.h/a.cpp irgendwann auf die Idee kommt, daß er die b.h nicht mehr braucht, hast du ein Problem.

(und wie gesagt, stellt es normalerweise kein Problem dar, wenn der Header doppelt eingebunden wird - Stichwort: Include Gurads)

akari

Hallo

b.h in b.cpp zu setzen

ist aber besser. So ist b immer als einzele Übersetzungseinheit zu kompilieren. Denn es kann sehr wohl sein, das in b.h notwendige Dekalrationen stehen, die b.cpp braucht. Beispiele sind Klassen, deren Deklaration in Header erfolgt, aber die Implementation in den cpp-Dateien. Hier würde ohne ein Include auf den eigenen Header ein Compilerfehler kommen.
Dein Weg geht zwar grundsätzlich auch, aber zieht unnötigerweise die Headerdatei von a mit in die Abhängigkeit.

Ob das nun ein so schwerwiegender Fehler ist, darüber kann diskutiert werden.

bis bald
akari

Artchi

Achso... naja, wenn du nur geraten hast, wird das sicherlich schief und somit falsch gegangen sein. Es ist schon wichtig, das mind. die Header inkludiert wird, die _benötigt_ wird. Das scheint ja in deiner Lösung nicht erfüllt worden zu sein? Ich habe dich zu erst so verstanden, das du _zusätzlich_ unnötige und mehrfach Header inkludiert hast. Aber meistens brauch a.cpp nunmal a.cpp. Wenn du gedacht hast "Naja, das sieht zu einfach aus, ich mach jetzt einfach mal a.cpp braucht b.cpp" dann ist das natürlich falsch! Und daraus schliesse ich, das du den Sinn der Header nicht verstanden hast. 6! Setzen!

Artchi schrieb:

Achso... naja, wenn du nur geraten hast, wird das sicherlich schief und somit falsch gegangen sein. Es ist schon wichtig, das mind. die Header inkludiert wird, die _benötigt_ wird. Das scheint ja in deiner Lösung nicht erfüllt worden zu sein? Ich habe dich zu erst so verstanden, das du _zusätzlich_ unnötige und mehrfach Header inkludiert hast. Aber meistens brauch a.cpp nunmal a.cpp. Wenn du gedacht hast "Naja, das sieht zu einfach aus, ich mach jetzt einfach mal a.cpp braucht b.cpp" dann ist das natürlich falsch! Und daraus schliesse ich, das du den Sinn der Header nicht verstanden hast. 6! Setzen!

Also die anderen header und source-dateien sind ja in Ordnung (habe ja auch a.h in a.cpp geschrieben). Geraten im eigentlichen Sinne hatte ich nicht, allerdings habe ich bei dieser doch kleinen Aufgabe nicht daran gedacht, dass mehrere Autoren damit arbeiten können sollten und dachte mir das es hierfür auch so funktioniert.

Also letztendlich, um das festzuhalten, muss b.cpp um seine b.h nutzen zu können auch a.h aufrufen und darin liegt der böse Fehler.

jerry

Warum zweifelt der arme Knecht an den Worten seines Profs?
Vermutlich macht der das doch schon a bissele länger,oder?

Gruss Jerry

akari

Hallo

Im (Informatik-) Unterricht geht es aber nicht um das blinde Glauben, sondern um Wissen und Hintergrund. Und deshalb ist es schlecht, das Prof nicht plausibel erklären konnte, warum die Lösung schlecht ist. Das hat Daniel erst hier verstanden (nehm ich mal an).

bis bald
akari

Knuddlbaer

Mittels Includeguards kann man einige Probleme beim wilden Includieren abfangen.

Nebst der Möglichkeit , das man um Fowärtsdeklarationen nicht herum kommt bzw. in der Praxis bei Korrekturen der Quellcodes der Azubis folgendes vorkommt:

a.h

#include "b.h"

class a
{
   b B;
};

b.h

#include "a.h"

class b
{
   erstelleausa(a & A);
};

was sich nach Rrücksprache stehts durch unüberlegtes includieren ergab, gibt es noch viel interesanntere Aspekte:

Jede .cpp Datei, die einen Header includiert (auch indirekt!) muss neu übersetzt werden, wenn sich ein Header ändert. Wenn man also ein Projekt hat, das aus vielen großen Übersetzungseinheiten besteht , und jede ÜE jeden Header includiert, bringt die Problematik mit sich, das sehr sehr viel Aufwand getrieben wird.

Wird z.B. dann in z.h etwas geändert, was eigentlich nur z.cpp betreffen würde, wird durch die includierung in alle anderen Units eine neue Übersetzung nötig, auch wenn aus dem Header z.h nichts verwendet wird.

jerry

@ akari: du solltest nur richtig lesen, was er will: er wollte wissen, ob die Bewertung zutrifft; er fragt nicht, wie und warum es richtig funktioniert. Sorry, die Genauigkeit verlangt die Informatik schon, oder ? Jerry

akari

Hallo

Und ein Informatiker sollte auch mitdenken können, anstatt nur nach Schema F zu arbeiten.
Es reicht eben nicht aus, ihm zu erklären das sein Prof grundsätzlich recht hat. Ein Informatiker/Wissenschaftler muß seine Aussagen auch begründen können, also gehört zu dieser Antwort auch die Begründung, warum man genau diese Antwort gibt.

bis bald
akari