include Häufigkeit minimieren



  • Hallo,
    Ich habe eine grundsätzliche Ordnungsfrage, zu der ich nichts im FOrum gefunden habe:

    Biblioteken wie <string> oder <iostream> brauche ich meistens sowohl in meiner Main-Funktion als auch in den verschiedenen Klassendeklarationen und Definitionen.

    Gibt es da einen Grundsatz wo ich die Biblioteken einbinde und wo nicht?

    Bzw. Reicht es vielleicht wenn ich de in einer Headerdatei von meiner Klasse einbinde und diese werden dann automatisch auch in den Klassendefinitions-Datei übernommen, bzw. ist es vielleiocht sinnvoll eine Datei nur mit includes zu schreiben und diese dann überall zu includieren? 🙂

    Würde mal gerne wissen, was da guter Stil ist.

    Danke

    Gruß
    NIklas



  • Hallo,

    Ja, falls du deinen Includes in einem Headerfile includierst, musst du dies nicht mehr im main.cpp machen.

    Ich persönlich binde die Headerdateien überall ein wo ich sie brauche, finde das Übersichtlicher.



  • niklasda schrieb:

    Gibt es da einen Grundsatz wo ich die Biblioteken einbinde und wo nicht?

    Ja, so wenig wie möglich im Header, das meiste kann in der .cpp eingebunden werden. Wenn im Header ein #include steht, wird das indirekt auch von allen anderen Sourcen eingebunden, die diesen Header einbinden.
    #includes im Header braucht man allgemein nur dann, wenn man
    - die eingebundene Klasse als Basisklasse oder Member der im header definierten Klasse benutzt
    - im Header Funktionen definiert (inline, templates), die die eigebundene Klasse benutzen
    - (komplizierte) typedefs aus dem anderen Header benutzen will (Paradebeispiel std::string)
    Du brauchst den Header nicht einzubinden, wenn du die definierte Klasse nur als Funktionsargument oder Rückgabetyp benutzt oder nur Pointer oder Referenzen darauf in der Klasse benutzt (Stichwort: Forward declaration)

    Bzw. Reicht es vielleicht wenn ich de in einer Headerdatei von meiner Klasse einbinde und diese werden dann automatisch auch in den Klassendefinitions-Datei übernommen,

    Ja, das reicht im Grunde. Wenn du also etwas im Header includieren musst, dann brauchst du es in der .cpp nicht mehr einbinden. Schadet aber auch nicht, da der Header dann trotzdem nur einmal eingebunden wird (Stichwort: Include guards).

    bzw. ist es vielleiocht sinnvoll eine Datei nur mit includes zu schreiben und diese dann überall zu includieren? 🙂

    Nein. Damit würdest du an anderen Stellen Header einbinden die du garnicht brauchst und dadurch unnötig Abhängigkeiten zur Compilezeit schaffen.

    Siehe auch hier:
    http://www.gotw.ca/gotw/007.htm
    http://www.gotw.ca/gotw/034.htm



  • Ich handhabe so, dass alle Klassen bei mir die STL Includes mit drin stehen haben, die sie benötigen um zu funktionieren. Damit kann ich diese Klassen locker flockig in einem anderen Projekt nutzen, ohne das ich mich erst 30 Minuten durch den Quellcode wursteln muss um zu schauen, welche STL Header ich nun noch inkludieren muss.

    Ich denk mal das es auch ein Thema ist, wo man die einen hat die es so machen und die anderen machen es wieder anders. Von daher ne Glaubenssache. Das mit den Abhängigkeiten stimmt schon, wie gesagt immer dort alles bündeln wo mans braucht. Mehrfach werden die STL Header eh nicht includiert, da diese ja auch einen HeaderGuard besitzen.



  • Blackskyliner schrieb:

    Ich handhabe so, dass alle Klassen bei mir die STL Includes mit drin stehen haben, die sie benötigen um zu funktionieren.

    Wie meinst du das?



  • daersc schrieb:

    Blackskyliner schrieb:

    Ich handhabe so, dass alle Klassen bei mir die STL Includes mit drin stehen haben, die sie benötigen um zu funktionieren.

    Wie meinst du das?

    so:

    #include <vector>
    #include <string>
    
    class Weinkeller
    {
       std::vector<std::string> flaschen;
    };
    

    Und wer "Weinkeller.h" inkludiert, muß nicht vorher <string> oder <vector> inkludieren.



  • volkard schrieb:

    daersc schrieb:

    Blackskyliner schrieb:

    Ich handhabe so, dass alle Klassen bei mir die STL Includes mit drin stehen haben, die sie benötigen um zu funktionieren.

    Wie meinst du das?

    so:

    #include <vector>
    #include <string>
    
    class Weinkeller
    {
       std::vector<std::string> flaschen;
    };
    

    Und wer "Weinkeller.h" inkludiert, muß nicht vorher <string> oder <vector> inkludieren.

    Ist das nicht ohnehin die "normale" Vorgehensweise?



  • daersc schrieb:

    Ist das nicht ohnehin die "normale" Vorgehensweise?

    Und es ist deshalb die "normale" weil ebenfalls auch beste Vorgehensweise.

    Einen geheimen Trick wie es besser geht gibt es nicht.



  • Shade Of Mine schrieb:

    Einen geheimen Trick wie es besser geht gibt es nicht.

    Und ich dachte schon ich hab was wichtiges versäumt 😃



  • Shade Of Mine schrieb:

    daersc schrieb:

    Ist das nicht ohnehin die "normale" Vorgehensweise?

    Und es ist deshalb die "normale" weil ebenfalls auch beste Vorgehensweise.

    Einen geheimen Trick wie es besser geht gibt es nicht.

    Du kennst ihn nur auch nicht ^^



  • Es gibt schon Tricks (Pimpl z.B.), aber die sind auch nicht der Weisheit letzter Schluss, weil sie eben eigene Probleme mit sich bringen.

    Gerade im Falle von zentralen Standardbibliotheks-Headern wie <string> oder <vector> ist die Abhängigkeit durchaus verkraftbar.



  • pumuckl schrieb:

    bzw. ist es vielleiocht sinnvoll eine Datei nur mit includes zu schreiben und diese dann überall zu includieren? 🙂

    Nein. Damit würdest du an anderen Stellen Header einbinden die du garnicht brauchst und dadurch unnötig Abhängigkeiten zur Compilezeit schaffen.

    Zu pauschal. Eine Datei, die Header inkludiert die oft gebraucht werden und die sich nie (oder quasi nie) ändern, und die dann als Precompiled Header eibinden, bringt ordentlich Speed beim kompilieren.



  • Nukularfüsiker schrieb:

    Eine Datei, die Header inkludiert die oft gebraucht werden und die sich nie (oder quasi nie) ändern, und die dann als Precompiled Header einbinden, bringt ordentlich Speed beim kompilieren.

    Selber gemessen?
    Ich habe den Eindruck, precompiled headers funktionieren nur auf Borland tadellos. Auf MS bringen sie nur was für <windows.h> und Konsorten. Was anderes in die "stdafx.h" zu stopfen, bringt weniger als Bescheidenheit beim Inkludieren. Und auf GCC hat es keinen Effekt.



  • volkard schrieb:

    Selber gemessen?

    Naja. Ich habe ein paar größere VC++-Projekte von teilweise furchtbarer include-Technik auf precompiled umgestellt. Es waren sich immer alle einig, dass es danach sehr viel schneller ging.
    Einen richtigen Test mit vernünftigen includes vs. precompiled und Zeitmessung habe ich nicht gemacht.

    Edit: hey, danke dass du meinen Schreibfehler im quote korrigiert hast 😃



  • volkard schrieb:

    Auf MS bringen sie nur was für <windows.h> und Konsorten. Was anderes in die "stdafx.h" zu stopfen, bringt weniger als Bescheidenheit beim Inkludieren.

    Da muss ich widersprechen. Zumindest unter MSVC++ 2008 spürt man einen deutlichen Gewinn. Für Header wie <vector> , <list> oder <boost/foreach.hpp> , die ich in vielen Modulen einsetze, spare ich durch vorkompilierte Headerdateien einiges an Kompilierzeit. Gemessen habe ichs nicht, aber es ging definitiv schneller.



  • ich habs mal gemessen bei nem größeren projekt.
    da war aber viel drin: standard-header, boost, ogre, ... ne ganze menge riesen zeugs halt.
    da war es von ner viertel stunde auf (wenn man was im pch geändert hat und der somit neu compiliert werden muss) 5minuten geschrumpft.
    wenn der pch nicht neu compiliert werden musste hatte sich die zeit glaube ich noch einmal halbiert.

    allerdings waren dort überdurchschnittlich viele includes in headern und auch noch im source-code mehrere zu viel...

    war mit dem msvc9.

    bb


Anmelden zum Antworten