all-include-header
-
Was haltet von dem Motto alle includes in eine headerdatei zu packen und diese dann in jeder einzeldatei zu includen?
z.B.
Projekt Tetris:
Tetris.h
#include <utility>
#include <boost\shared_ptr.hpp>
#include <Math.h>
#include <Klotz.h>
#include <Steuerung.h>Math.h
#include <Tetris.h>Klotz.h
#include <Tetris.h>Steuerung.h
#include <Tetris.h>Aus meiner Sicht:
Pros
.Schreibaufwand bei Erweiterungen gering.Cons
.Modularität - Scheiss drauf
.Compile-Zeit
-
Wenn man nur mal was ausprobieren will, ist so ein All-in-One-Header sehr hilfreich.
Aber wenn man ein ernsthaftes Projekt arbeitet, sollte man sich die Mühe machen, und nur die nötigen Header zu inkludieren.
-
Das darfst du dann machen, wenn du alle Fragen die hier im Forum gekommen sind, weil die Leute mit dieser Technik auf die Fresse gefallen sind gefunden und gelesen hast, und du verstanden hast, warum es dabei Fehler zu Fehlern gekommen ist. Aber wahrscheinlich willst du es dann gar nicht mehr so machen. Außerdem wirst du sehr alt sein, bis du alle darauf beruhenden Threads gelesen hast.
-
ZeroXCola schrieb:
.Schreibaufwand bei Erweiterungen gering.
Wenn der Schreibaufwand ein paar Header einzubinden wirklich dein größtes Problem ist, dann mal los.
-
ZeroXCola schrieb:
Aus meiner Sicht:
Pros
.Schreibaufwand bei Erweiterungen gering.Cons
.Modularität - Scheiss drauf
.Compile-ZeitStimmt, damit hast kein Pro und zwei gute Gründe dagegen.
-
Kein Ahnung ob das heute noch so ist.
In der Vergangenheit gab es gleichnamige Funktionen, die aber nicht gleich waren, in verschiedenen Headern.
Da kommt es dann auf die Reihenfolge der Header im Quelltext an.Wenn man nur Header eingibt, die für den Quelltext notwendig sind, ist die Gefahr geringer sich da Probleme einzufangen.
Beispiel:
#include<string.h> #include<string> #include<cstring>da funktionieren dann die Quelltexte oft anders als vom Schreiber gewünscht.
Zu deinem Tertris - möglichst die gleichzeitige Nutzung von C und C++ Headern vermeiden.
Und was man auch hin und wieder findet:
using namespace std;gar nicht in selbst geschriebenen Headern.
Das mag in kleinen Projekten funktionieren, bringt in mittleren bis grösseren Projekten aber in der Regel Ärger.
-
die ersparnis an Schreibaufwand relativiert sich dann wieder durch die Notwendigkeit von include guards
-
f.-th. schrieb:
Kein Ahnung ob das heute noch so ist.
In der Vergangenheit gab es gleichnamige Funktionen, die aber nicht gleich waren, in verschiedenen Headern.
Da kommt es dann auf die Reihenfolge der Header im Quelltext an.Das verstehe ich nicht so ganz, wie kann das jemals der Fall gewesen sein? Es kann keine doppeldeutigen Funktionsnamen in C++ geben.. (a.k.a. Das gibt nen Compilerfehler.)
-
!rr!rr_. schrieb:
die ersparnis an Schreibaufwand relativiert sich dann wieder durch die Notwendigkeit von include guards
Hast du ansonsten keine?
-
SeppJ schrieb:
!rr!rr_. schrieb:
die ersparnis an Schreibaufwand relativiert sich dann wieder durch die Notwendigkeit von include guards
Hast du ansonsten keine?
Is zuviel schreibarbeit, mann.
-
genau
-
ZeroXCola schrieb:
Was haltet von dem Motto alle includes in eine headerdatei zu packen und diese dann in jeder einzeldatei zu includen?
Alle? Nein, aber die meisten ist eine gute Idee -> Stichwort: precompiled header.
-
Shade Of Mine schrieb:
ZeroXCola schrieb:
Was haltet von dem Motto alle includes in eine headerdatei zu packen und diese dann in jeder einzeldatei zu includen?
Alle? Nein, aber die meisten ist eine gute Idee -> Stichwort: precompiled header.
-
Shade Of Mine schrieb:
Alle? Nein, aber die meisten ist eine gute Idee -> Stichwort: precompiled header.
Auch wieder so ein Feature, bei dem 10% weniger Fragen im Forum kämen, wenn es das nicht gäbe
.edit: Oder besser gesagt: Wenn es nicht standardmäßig aktiv wäre. Gegen gute Features, bei denen man bei Benutzung aufpassen muss, habe ich an sich nichts.
-
Besser gefragt: warum brauchen wir überhaupt Header-Dateien?
Ohne Header-Dateien würden solche Fragen erst überhaupt nicht auftreten, und dann wäre auch PCH unnötig.
-
Artchi schrieb:
Besser gefragt: warum brauchen wir überhaupt Header-Dateien?
Ohne Header-Dateien würden solche Fragen erst überhaupt nicht auftreten, und dann wäre auch PCH unnötig.Weil sich vor ca. 40 Jahren mal jemand gedacht hat, dass header Dateien eine gute Idee sind.
-
Gruum schrieb:
Weil sich vor ca. 40 Jahren mal jemand gedacht hat, dass header Dateien eine gute Idee sind.
Ohne Klassen aber insbesondere ohne Templates sind sie das ja auch. Zu C++ passen sie aber leider so gar nicht mehr.
-
314159265358979 schrieb:
http://gamesfromwithin.com/the-care-and-feeding-of-pre-compiled-headers
Wenn du mal groß bist, wirst auch du den Sinn von PCH verstehen
Es hat seinen Grund warum alle großen Compilerhersteller PCH supporten und in jeder Doku wirst du etwas derartiges lesen:
Clang Documentation schrieb:
Precompiled headers are a general approach employed by many compilers to reduce compilation time. The underlying motivation of the approach is that it is common for the same (and often large) header files to be included by multiple source files. Consequently, compile times can often be greatly improved by caching some of the (redundant) work done by a compiler to process headers. Precompiled header files, which represent one of many ways to implement this optimization, are literally files that represent an on-disk cache that contains the vital information necessary to reduce some of the work needed to process a corresponding header file. While details of precompiled headers vary between compilers, precompiled headers have been shown to be highly effective at speeding up program compilation on systems with very large system headers (e.g., Mac OS/X).
-
Vorkompilierte Header braucht nicht, wer ordentlich mit seinen Headern und Includes umgeht. Das mit dem groß werden kannst du ja mal volkard sagen, wenn er wieder da ist.
-
314159265358979 schrieb:
Vorkompilierte Header braucht nicht, wer ordentlich mit seinen Headern und Includes umgeht.
Das ist einfach nur falsch.
Wenn du zB Datei foo.h in 3 .cpp Dateien inkludierst, muss diese 3 mal kompiliert werden. Wenn diese foo.h nun sehr gross ist, weil sie zB generellen Framework Code enthaelt dann wird diese pro .cpp Datei kompiliert. Bei PCH hat man den Aufwand sage und schreibe 0 mal. Wenn du also zB eine Header Datei nimmst, die du gerne verwendest, wie zB <string>, dann machen wir ne kleine Anschauung:
Bei meinem VC++ ist <string> 21KB gross und haengt von <istream> ab. Diese ist 34KB gross und haengt von <ostream> ab. Diese ist 30KB gross und haengt von <ios> ab. Diese ist 10KB gross und haengt von <xlocnum> ab. Diese ist 51KB gross und haengt von <climits>, <cmath>, <cstdio>, <cstdlib> und <streambuf> ab. Und hier hoere ich jetzt mit dem zaehlen auf.
Wenn ich <string> das ich in einen grossteil meiner Modulen brauche in einen PCH packe, reduziere ich die Zeit die ich fuers kompilieren brauche enorm. Schau mal wieviel KB das sind nur fuer ein dummes std::string.
Im Endeffekt kann man natuerlich sehr viel Zeit sparen indem man die Header inkludierung limitiert und nur die notwendigen Header einbindet - das ist vollkommen logisch. Aber wenn man das schon getan hat, helfen PCH nochmal enorm. Und PCH helfen auch enorm wenn man nicht haendisch optimiert
PCH bringen nur Vorteile und keine Nachteile. Der einzige Nachteil den es theoretisch gibt ist der, dass es die portierbarkeit des Codes zwischen einzelnen Compilern erschwert - andererseits: wenn ein Compiler keine PCH kann, dann kann ich dort mit laengeren Buildzeiten leben.
