Header files



  • Wieso braucht man header files.
    Jetzt mal ernsthaft. Anstatt hello.h koennte man doch auch einfach hello.cpp einbinden. Klar so ein header file, zeigt dir mal die Schnittstellen und ist frei von der Implementierung. Das ist schon uebersichtlicher. Aber sonst seh ich echt keinen Vorteil. Nehmen wir mal C Sharp da bindet man ja auch einfach die Klasse ein. So koennte man es doch auch in C++ machen.



  • übersichtlichkeit, kompilierzeit, klassen-querverweise (vorwärtsdeklaration)



  • Man braucht sie noch. Mit C++ Modules wird das wohl anders.



  • Wieso muss man bloß diese schöne Sprache so verschlimmbessern... Was spricht denn gegen die Trennung von Header und Source? Sehe schon kommen dass Header Files bald genauso verpöhnt sind wie Raw-Pointer oder goto. Alles Blödsinn.



  • ich finds ja auch cool. Aber warum ist es in C# NICHT noetig ?
    Bislang hat sich noch KEINER beschwert dass es nicht C# keine header files gibt oder



  • Bei C und C++ werden die Source-Dateien einzeln kompiliert und daraus Objectfiles erzeugt, gegen die dann gelinkt wird. Daher benötigt jeder Kompiliervorgang (d.h. jede Übersetzungseinheit) die kompletten Deklarationen aller verwendeten Typen. Und um das nicht jedesmal wieder neu je Source-Datei zu schreiben, werden dafür die Header-Files eingebunden.

    Bei C# werden Assemblies erzeugt, welche die kompletten Meta-Daten (u.a. auch wegen Reflection) erhalten, so daß aus diesen diese Infos für den Kompiliervorgang herangezogen werden können.



  • Vici schrieb:

    Nehmen wir mal C Sharp da bindet man ja auch einfach die Klasse ein.

    Man bindet aber nicht den Quellcode der Klasse ein, sondern das Kompilat (im C#-Sprech "Assembly"), das außer dem ausführbaren Code auch eine Interface-Beschreibung enthält.

    Das machen übrigens alle "modernen" Sprachen so, angefangen bei TurboPascal. So gesehen ist C++ in der Tat gewissermaßen ein Überbleibsel längst vergangener Zeiten. Was seiner Beliebtheit aber nicht schadet.



  • Vici schrieb:

    Klar so ein header file, zeigt dir mal die Schnittstellen und ist frei von der Implementierung. Das ist schon uebersichtlicher.

    Wenn das mal wirklich so wäre. Die Header müssen ja mehr als nur die Schnittstelle enthalten: sie enthalten auch private Implementierungsdetails wie die Member-Variablen und auch die privaten Funktionen. Alternativ kann man in Header erkennen, dass die Klasse das Pimpl-Idiom nutzt (dann sieht man die privaten Member nicht).

    Punkt 2 sind die Templates - auch die sind komplett im Header.

    Ich kommt von Turbo Pascal -> Delphi -> Java -> C++. In Turbo Pascal gab es damals schon Units (in Delphi dann auch). Ich finde es nur nervig, im Header einfach die Funktionsdeklaration wiederholen zu müssen. Außerdem kann man 1-zeiler-Funktinnen auch einfach inline im Header implementieren. Also mal steht was im .h, mal im .cpp. Noch dazu führen diese Header zu längeren Compile-Zeiten. Ein Riesenprojekt in Turbo-Pascal (auf damaliger Hardware) oder in Java (aktuell) zu kompilieren geht unglaublich schnell, C++ kompiliert sehr lahm!

    Auch noch nervig mit .h/.cpp: Je nach Projekt liegen die unterschiedlich. Mal im selben Verzeichnis. Mal Header in inc, .cpp in src, mal liegen Header in $projectRoot/package/include/package/subpackage. Und wer weiß, ob nicht das Buildsystem erstmal alle Header zusammensammelt und nach build/include kopiert - ist ganz großartig, diese Vielfalt 😞

    Und wenn ich mit clang-tidy Code analysiere, habe ich im Output vielfach bestimmte Meldungen aus einer Header-Datei, die ich nachträglich dann erstmal unique machen muss.

    Genug geklagt: Also, sobald was besseres als .h möglich ist, würde ich es gern sofort benutzen.



  • solange die möglichkeit header zu nutzen beibehalten wird, ist mir alles egal 😃 wenn es so wird wie z.b. php, wo man entweder einen langen header kommentar erstellen muss indem alle funktionen aufgelistet sind oder 1x komplett durchscrollt um herauszufinden wie die klasse aufgebaut ist, dann nein danke.

    wie soll das eigentlich dann funktionieren wenn man 3rd party libraries erstellt? bisher haben wir die lib kompiliert rausgegeben und die header beigepackt.