Hashtable

Kann ich mir damit nun #include <string> sparen? (Auch auf die Gefahr hin, dass diese Frage dumm klingt - aber ich bin Anfänger und muss Fragen stellen)
Fragen darf man immer.
Den Header brauchst du aber auch immer, wenn du eine darin definierte Klasse nutzt ;-)

Includes/Definitionen würde ich generell lieber in die Headerdatei packen.

Gruss
cwriter
 
Wenn du alle benötigten includes in einen Header packst und diesen Header dann in der main.cpp (oder einfach der Basisdatei) inkludierst, reicht das.
Weiterführend: Vorkompilierter Header (stdafx.h).

Gruss
cwriter
 
Also muss ich diese #includes-Geschichten gar nicht überall reinpacken, solange die vollständig in der Headerdatei sind? :/

Hi,

falls du aber weiter C/C++ programmieren willst und dich dabei nicht nur auf kleinere Privatprojekte beschränken willst, dann solltest du dich an einen gewissen Stil gewöhnen.

Ein #include mehr oder weniger wird dich nicht umbringen, zumal der Compiler schon selbst merken wird, ob die Header-Datei schon vorhanden ist oder noch fehlt. Diese wird dann evtl. gar nicht erst wieder inkludiert.

Ich persönlich denke ein include gehört immer in die Datei, wo der Inhalt auch benötigt wird. Ansonsten kommst du schnell zu Problemen, wenn mal die Reihenfolge der includes nicht stimmt oder du mal ein ganzes Modul ersetzt oder löscht.

Wenn du davon ausgehst, dass du eine config.h sowieso in allen deinen Headern nutzen willst/musst, dann kann man dort zur Einfachheit auch alle includes hineinpacken um alle schnell zu ändern und im Überblick zu behalten. Aber denk immer daran, dass man selbst und andere bei Fehlern evtl. danach suchen müssen.

Zu deiner using Frage noch folgenden Nachtrag. In der main gerne benutzen, aber in Headern kein guter Stil, denn stell dir vor du hast eine Funktion cout im namespace std, nutzt aber auch eine eigene Funktion cout, die ähnliches macht. Welche ist nun gemeint? Die aus std oder deine? Auch wenn das Beispiel mit cout jetzt nur oben aufgegriffen wurde und nicht das beste ist, kann es bei der Menge an Funktionen aus dem C++ Standard doch mal dazu kommen. (Bsp. die Funktion sort, hash etc.)

Grüße,
Jennesta
 
Ein #include mehr oder weniger wird dich nicht umbringen, zumal der Compiler schon selbst merken wird, ob die Header-Datei schon vorhanden ist oder noch fehlt. Diese wird dann evtl. gar nicht erst wieder inkludiert.

Du hast schon Recht, es wird mich nicht umbringen und ich werde es auch einfach so beibehalten wie gehabt.... es hat für mich ersteinmal danach geklungen, deshalb habe ich auch nachgefragt.


Zu deiner using Frage noch folgenden Nachtrag. In der main gerne benutzen, aber in Headern kein guter Stil, denn stell dir vor du hast eine Funktion cout im namespace std, nutzt aber auch eine eigene Funktion cout, die ähnliches macht. Welche ist nun gemeint? Die aus std oder deine?

Ah, jetzt verstehe ich das. Ja das macht so Sinn und so hat es auch funktioniert, als ich es ausprobiert habe.

Vielen Dank auch nochmal für die Stilhinweise, falls es paar klassische Anfänger-Stilprobleme geben sollte, dann wäre ich offen für Hinweise. Wenn, dann richtig :)
 
Ich persönlich denke ein include gehört immer in die Datei, wo der Inhalt auch benötigt wird. Ansonsten kommst du schnell zu Problemen, wenn mal die Reihenfolge der includes nicht stimmt oder du mal ein ganzes Modul ersetzt oder löscht.

Wenn du davon ausgehst, dass du eine config.h sowieso in allen deinen Headern nutzen willst/musst, dann kann man dort zur Einfachheit auch alle includes hineinpacken um alle schnell zu ändern und im Überblick zu behalten. Aber denk immer daran, dass man selbst und andere bei Fehlern evtl. danach suchen müssen.

Kann ich nicht nachvollziehen. Gerade bei Winsock (pragma comment(lib,"ws2_32.lib") und #include <winsock2.h>) habe ich die Erfahrung gemacht, dass es einfacher ist, die Header nur in eine Datei zu schreiben, eben darum, weil die Reihenfolge sonst nicht immer klar ist und man riesige Labyrinthe konstruieren kann.
Grundsätzlich sollte man ja nichts schreiben, das mit einem anderen Header kollidieren wird (wie eben z.B. cout), schlicht weil es ein Standard ist und man den nicht überschreiben sollte.
Und zu viele Header tun soweit auch nicht weh, wenn man denn Zeit und Lust hätte, könnte man sich die Windows.h auch komplett selbst neu schreiben und auf alle darin inkludierten Dateien verweisen...

Oder gibt es einen konkreten Fall, in dem man nicht zu viele Header haben sollte?

Gruss
cwriter
 
Kann ich nicht nachvollziehen. Gerade bei Winsock (pragma comment(lib,"ws2_32.lib") und #include <winsock2.h>) habe ich die Erfahrung gemacht, dass es einfacher ist, die Header nur in eine Datei zu schreiben, eben darum, weil die Reihenfolge sonst nicht immer klar ist und man riesige Labyrinthe konstruieren kann.
Grundsätzlich sollte man ja nichts schreiben, das mit einem anderen Header kollidieren wird (wie eben z.B. cout), schlicht weil es ein Standard ist und man den nicht überschreiben sollte.
Und zu viele Header tun soweit auch nicht weh, wenn man denn Zeit und Lust hätte, könnte man sich die Windows.h auch komplett selbst neu schreiben und auf alle darin inkludierten Dateien verweisen...

Oder gibt es einen konkreten Fall, in dem man nicht zu viele Header haben sollte?

Gruss
cwriter

Ich habe leider sehr wenig mit Winsock gearbeitet, noch den pragma Stil für das lib includen übernommen. Ich weiß auch nicht, ob wir da vielleicht etwas anderes meinen oder ich mich unglücklich ausgrdrückt habe.

Was ich meinte ist halt bei eigenen Headern, dass man dort nur die z.B. math header inkludiert, wenn man sie auch nutzen will. Wenn man dann z.B. auch das M_PI nutzen möchte, weiß man auch wo man das #define setzen muss und muss nicht durch zahlreiche Header suchen. Auch gehe ich davon aus, dass ich meine Header mehrfach verwende. Dann wäre natürlich unschön bei der Benutzung auf einmal einen Fehler zu bekommen, weil irgendeine notwendige Header fehlt.

Das was du vielleicht meinst, mit der Reihenfolge sehe ich ähnlich. Aber da sind bei Winsock (finde ich) die Vorraussetzungen auch irgendwie anders. Normalerweise sollte eine header Datei ja auch die Dateien inkludieren, die für die eigene reibungslose Funktion notwendig sind.

Und wie ich schrieb. Gegen eine config.h, die alle header inkludiert, habe ich auch prinzipiell nichts gegen. Nur sollte man da nicht übertreiben und wirklich nur die notwendigen Dinge reinpacken, wie globale Variablen und Konstanten und includes die überall rein müssen.

Edit:
Ich denke nebenbei, dass es wohl auch eine Art Philosophiefrage ist. Solange man seinen Stil konsistent macht dürfte das keine Probleme machen. Je nachdem wessen Software man nutzt sieht man das auch.
 
Zuletzt bearbeitet:
Zurück