Haben Headerdateien eigentlich Vorteile?



  • @daHa: ich bin der Meinung von Artchi. Erklär uns doch mal das Konzept der Headerdateien

    Ein Artikel über das Thema "Sinn von Headerdateien" wäre doch echt interesant 😉

    bisheriger Stand:
    Sinn von Headerdateien:
    1. Erleichtert Compilerbauern die Arbeit (siehe Optimizer)

    Argumente die ich nicht gelten lassen Kann:
    1. Ermöglichen einfache Auslagerung von Code
    2. Ermöglichen Code in verschiedenen Anwendungen zu benutzen
    3. gesamte Schnittstelle einer Klasse auf einen Blick

    diese Punkte kann man auch ohne viel Aufwand in Programmiersprachen
    ohne Header Dateien erreichen (z. B . Java oder C#) oder unter zuhilfenaheme einer kostenlosen IDE



  • Artchi schrieb:

    Naja, zu sagen "ihr habts eh nicht verstanden" um keine Argumente liefern zu brauchen, ist hier nicht relevant. Du hast keinen einzigen Punkt für Header geliefert. Du hast nur gesagt "Ihr seid doch eh doof!".

    Bin ich hier im Kindergarten? 😃

    😮

    eine sehr eigenwillige interpretation von dir, aber wenn du es so interpretieren wills, bitte.

    im uebrigen brauch in kein argument pro header bringen, das sie zum konzept mancher sprachen und der zugehoerigen kombi preprozessor/kompiler gehoehren is halt so.

    und das es fuer manche sinn macht ist halt auch so.

    ob das jetzt jeder versteht is mir egal, allerdings darf ich meine meinung zum besten geben wenn ich manche argumente als schwachsinn interpretiere, so wie du deine meinung zum besten gegeben hast.

    allerdings, deine forumlierten verallgemeinerte unterstellungen find ich in meinem post nicht, desswegen weis ich schon drauf hin das ich das was du mir unterstellst so nicht geschrieben hab.



  • @daHa: ich bin der Meinung und wahrschienlich auch Artchi, dass du es selbst nicht peilst und deshalb fordere ich dich auf, das Konzept von Headerdateien zu erklären.



  • Das Konzept der Header bauch er uns nicht erklären, das kann jeder in seinem C++ Buch tun. 🙂 Nur geht es ja um Vorteile, wie das im Topictitel heißt. Und darauf warte ich immer noch.



  • Vertexwahn schrieb:

    @daHa: ich bin der Meinung von Artchi. Erklär uns doch mal das Konzept der Headerdateien

    Ein Artikel über das Thema "Sinn von Headerdateien" wäre doch echt interesant 😉

    bisheriger Stand:
    Sinn von Headerdateien:
    1. Erleichtert Compilerbauern die Arbeit (siehe Optimizer)

    Argumente die ich nicht gelten lassen Kann:
    1. Ermöglichen einfache Auslagerung von Code
    2. Ermöglichen Code in verschiedenen Anwendungen zu benutzen
    3. gesamte Schnittstelle einer Klasse auf einen Blick

    diese Punkte kann man auch ohne viel Aufwand in Programmiersprachen
    ohne Header Dateien erreichen (z. B . Java oder C#) oder unter zuhilfenaheme einer kostenlosen IDE

    wenn du deine java c# sonstiges welt 1 zu 1 umsetzten wills, bitte du das.

    wenn du deine erfahrungen mit java c# sonsiges IDEs fuer alles umsetzten willst bitte tu das.

    wenn du keinen sinn darin siehst das es manchmal doch recht praktisch ist header zu verfuegung zu haben dann hat sich dir die ein oder andere situation noch nicht so gestellt, oder du hast sie anders geloest.

    wenn du alle die leute die das konzept definition / impelmentation getrennt moegen als antiquierte ideoten siehst die die herrlichkeit anderer neuerer sprachen konzepte nicht verstanden haben, dann bitte tu das.

    und wenn irgendwer immer wieder halbgares technisches knowhow von sich gibt und du das kritiklos zur kentniss nehemn willst, dann bitte tu das.

    ich hab keine lust dich von irgendwas zu ueberezugen, noch dazu wo eigentlich einiges/vieles, je nach argument, davon persoenlicher geschmack ist.

    ueber so argumente wie das es nervig ist an 2 stellen signaturen zu aendern, naja, ich seh da recht wenig diskusionsgrund, ausser das ich dir sagen kann das es mich nicht stoehrt.



  • Artchi schrieb:

    Naja, zu sagen "ihr habts eh nicht verstanden" um keine Argumente liefern zu brauchen, ist hier nicht relevant. Du hast keinen einzigen Punkt für Header geliefert. Du hast nur gesagt "Ihr seid doch eh doof!".

    Bin ich hier im Kindergarten? 😃

    Naja

    daHa schrieb:

    wer IDE fixiert ist war anscheinend noch nie auf einem rechner vorort im einsatz wo seine lieblingside nicht vorhanden ist, bzw tatsaechlich auf einen editor beschraenkt ist.

    hört sich für mich schon nach einem Argument an: mit Headern braucht man eben keine resourcenintensive IDE, da die u.U. nicht überall verfügbar ist.



  • Feststellung: Red-Tiger und daHa überzeugen nicht. Wie Artchi schon festgestellt hat, ist die einzige Aussage der Postings "ihr peilt es nicht".



  • @daHa: erst sagst du wir kapieren das Konzept der Headerdateien nicht - und du willst es uns aber auch nicht erklären

    inzwischen haben dir schon 3 Leute gesagt, das dein Beitrag einfach voll daneben ist



  • OK, ich versuche es mal. 🙂

    Ob das jetzt irgendwelche Vorteile im generellen sind weiß ich nicht, aber ich sehe das als solche an. Wie das in anderen Sprachen (Java, C#, etc.) gelöst wird weiß ich auch nicht.

    1. Ich habe eine Trennung von Schnittstelle und Implementierung. Was mich bei Java irgendwie stört. Ich kann nicht einfach ne Datei öffnen und habe die komplette Schnittstelle vor Augen. Zugegeben, ich habe Java nur kurz an der Uni gemacht und kenne mich nicht wirklich aus. Aber eine Übersicht in der IDE aus der Quelldatei generiert erfüllt denselben Zweck. Ich finde es nur schöner, wenn das Sprachkonzept so etwas schon unterstützt. Ich entwickle ebenfalls mit PHP, wo ich mit einem simplen Texteditor arbeite, wobei es mich mittlerweile sehr stört, dass ich den Code nicht so schön trennen kann.

    2. Wenn ich eine Bibliothek schreibe, dann muss ich an die Benutzer der Bib. lediglich die Header und die lib/dll liefern. Ich glaube man kann die private Sachen auch völlig rausschmeißen und der Code, der die Lib verwendet kann problemlos kompiliert werden. Wenn ich eine dll schreibe und gleichzeit die lib generiere, dann brauche ich mich nicht darum zu kümmern wie die Funktionen in der dll heißen, die IDE kann die Informationen direkt aus den Headern ziehen, dann wird noch kurz die kleine lib dazugelinkt und fertig. Auch hier weiß ich nicht, wie das in anderen Sprachen gelöst wird, wäre aber für Informationen dankbar. 🙂

    Ansonsten sehe ich keine wirklichen Vorteile, aber Probleme auch nicht wirklich. 😃



  • mantiz schrieb:

    OK, ich versuche es mal. 🙂

    1. Ich habe eine Trennung von Schnittstelle und Implementierung. Was mich bei Java irgendwie stört. Ich kann nicht einfach ne Datei öffnen und habe die komplette Schnittstelle vor Augen. Zugegeben, ich habe Java nur kurz an der Uni gemacht und kenne mich nicht wirklich aus. Aber eine Übersicht in der IDE aus der Quelldatei generiert erfüllt denselben Zweck. Ich finde es nur schöner, wenn das Sprachkonzept so etwas schon unterstützt. Ich entwickle ebenfalls mit PHP, wo ich mit einem simplen Texteditor arbeite, wobei es mich mittlerweile sehr stört, dass ich den Code nicht so schön trennen kann.

    jede IDE hat einen Objektbrowser

    2. Wenn ich eine Bibliothek schreibe, dann muss ich an die Benutzer der Bib. lediglich die Header und die lib/dll liefern. Ich glaube man kann die private Sachen auch völlig rausschmeißen und der Code, der die Lib verwendet kann problemlos kompiliert werden. Wenn ich eine dll schreibe und gleichzeit die lib generiere, dann brauche ich mich nicht darum zu kümmern wie die Funktionen in der dll heißen, die IDE kann die Informationen direkt aus den Headern ziehen, dann wird noch kurz die kleine lib dazugelinkt und fertig. Auch hier weiß ich nicht, wie das in anderen Sprachen gelöst wird, wäre aber für Informationen dankbar.

    geht z. B. mit Assemblies genau so...

    Ansonsten sehe ich keine wirklichen Vorteile, aber Probleme auch nicht wirklich.

    es ist halt störend, dass man nicht gleich direkt in die Deklaration den Code schreiben kann, auch wenn es da Hilfen von der IDE gibt. Ich persönlich schreibe erst meinen Code in die Headerdatei/also mach alle Methode inline (was der Compiler aber soweiso in den meisten fällen, wieder ignoriert) - erst wenn der Code problemlos läuft Trenne ich Dekleration und Definiton - für mich unnötige Arbeit



  • Redundanz ist eines der schlimmsten Sachen.



  • Vertexwahn schrieb:

    @daHa: erst sagst du wir kapieren das Konzept der Headerdateien nicht - und du willst es uns aber auch nicht erklären

    inzwischen haben dir schon 3 Leute gesagt, das dein Beitrag einfach voll daneben ist

    wer ist wir,

    wem hab ich was unterstellt, ausser das ich technische erklaehrungen angezweifelt hab die ich als halbgar empfinde und die header impl aufteilung als altmodisch und nachteilig darstellen, und das anhand einer argumentation die so nicht richtig ist bzw derartig verschwommen gebracht wurde das man sich schwer tut daraus die erklaehrung zu sehen/verstehen.

    und das es halt nicht optimal ist die erfahrungen die man mit einer java ide gemacht hat 1 zu 1 auf c/c++ umlegen zu wollen, weil das nicht geht.
    (siehe seite 1)

    ich hab auch nie irgendwo behauptet das header/impl konzept ueberlegen oder sonst was ist.

    ich erklaehrs aber auch nicht als nachteilig, sondern im endeffekt zu persoenlichen geschmack.

    das is aber anscheinend ueberlesen worden.

    warum hab ich das gefuehl das es besser is mit gewissen java mullahs eigentlich gar nicht zu kommunizieren?
    weil immer kommt man durch irgendeinen bloedsinn oder freie interpretationen die an unterstellungen grenzen total vom thema ab.



  • "wenn man das konzept header datein nicht verstanden hat weis man nicht wozu sie gut sind, das ist klar. " <- da hast du Deine Unterstellung. Gesagt wozu sie deiner Meinung nach gut sind hast du dann auch nicht, hättest ja machen können oder einfach gar nichts sagen. Daran dass Du vom Thema abkommst und belangloses Zeug postest sind keine gemeinen "Javamullahs" Schuld. ⚠

    Zum Thema keine Nachteile: Das Kompilieren dauert länger, man muss mehr schreiben, man muss auch noch wissen wie man das macht und darf es nicht vergessen oder falsch machen etc.



  • Vertexwahn schrieb:

    es ist halt störend, dass man nicht gleich direkt in die Deklaration den Code schreiben kann, auch wenn es da Hilfen von der IDE gibt. Ich persönlich schreibe erst meinen Code in die Headerdatei/also mach alle Methode inline (was der Compiler aber soweiso in den meisten fällen, wieder ignoriert) - erst wenn der Code problemlos läuft Trenne ich Dekleration und Definiton - für mich unnötige Arbeit

    klar das einem header impl trennung nervt wenn man so arbeitet.

    is es nicht ein leichter wiederspruch auf der einen seite ide features als allgegenwaertig und immer benutzbar anzupreisen, unverzichtbar fuer die uebersicht, (objectbrowser) , aber auf der anderen seite andere ide features nicht zu nutzen?

    lass mal den objectbrowser genauso weg wie andere ide hilfen und argumentier dann noch mal bez uebersichtlichkeit, oder waer dir das zu wenig einseitung und zu objektiv?



  • Optimizer schrieb:

    Ich starte schon immer Visual Studio kurz.

    Kurz starten reicht leider nicht. Um im Class View was zu sehen muss man ein Projekt erstellen bzw. laden und wenn man mehr als 10 Klassen hat, dauert es schon ein wenig..

    In welcher Traumwelt lebt ihr? Ihr dürft doch nicht davon ausgehen, dass ihr immer mit einer beliebigen IDE arbeiten könnt. Ich war letztens in einem Projekt beschäftigt (viel mit Sicherheit) und durfte daher nur Eigenentwicklungen der entsprechenden Firma verwenden. Da war nichts mit Refactoring oder Class View.



  • klar das einem header impl trennung nervt wenn man so arbeitet.

    der Objektbrowser ist halt ausgereifter, wie die Autogenerierung von einem Grundgerüst aus einer Klassendeklaration. Du kennst doch bestimmt diese Spielereien - du änderst in der Definition einen Parameter einer Funktion und vergisst den Parameter auch in der Deklaration zu ändern. Wenn man an die Implementierung geht und das Klassenkonzept und die Anforderungen noch nicht ausgereift sind, dann muss man oft mal Parameter, Rückgabetypen oder einfach nur Methodennamen ändern.
    Damit kommen manche IDEs nicht so gut zurecht. Ich dachte halt Objektbrowser funktioniert immer - Autogenerierung nicht. Aber vergiss das Beispiel. Du hast recht ein gute IDE sollte das können.



  • gogno schrieb:

    "wenn man das konzept header datein nicht verstanden hat weis man nicht wozu sie gut sind, das ist klar. " <- da hast du Deine Unterstellung.

    wenn du diesen satz allein betrachtest kann ich verstehen das du zu einer unterstellung kommst.

    verzeihung an alle die sich betroffen gefuehlt haben.

    es tut mir leid das ich anscheinend so schlampig formuliere das es dir unmoeglich ist diesen satz im zusammenhang zu lesen, aber event liesst du noch mal die ersten eineinhalb seiten des threads, event verstehst dann meine formulierungen bzw das was ich sagen wollt aber nich in romanform ausformuliert hab.



  • daHa schrieb:

    gogno schrieb:

    "wenn man das konzept header datein nicht verstanden hat weis man nicht wozu sie gut sind, das ist klar. " <- da hast du Deine Unterstellung.

    wenn du diesen satz allein betrachtest kann ich verstehen das du zu einer unterstellung kommst.

    Lustigerweise steht der Satz auch ganz alleine da, direkt am Anfang Deines Postings, nachdem Deine sämtlichen Argumente fachgerecht zerlegt wurden. Wer käme da wohl auf die Idee, Du willst Deinen Kritikern Unwissenheit vorwerfen?



  • Ach ich geb jetzt auch mal meinen Senf dazu, kann man ja net anschaun hier 😃

    Ich persönlich halte dieses Headerkonzept für daneben!

    Ich verstehe die Argumente die dafür sprechen und wenn man sich überlegt wie alt C bzw. C++ sind, dann kann man auch verstehen wieso dieses Konzept verwendet wurde. Es hat damals seinen Zweck erfüllt, hat dafür gesorgt das die Kompiler einfach bleiben konnten und man war glücklich.

    Aber jeden Tag werde ich auch mit den Gemeinheiten dieses Konzeptes geärgert.
    Wie z.B(bezieht sich jetzt auf C).:
    Die Includereihenfolge muss fest stehen: Dadurch das die Includes nichts weiter als Textersetzung sind, habe ich das Problem das ich genau in der Reihenfolge einbinden muss, dass zum Schluss ein File entsteht wo alles schön nach der Reihenfolge der Verwendung angeordnet ist. Das mag gut gehen bei nem Projekt das man selber schreibt und überschaubar ist. Aber sobald man in eigenen Quellcode Fremdcode integrieren muss, auf den man keinen Einfluss haben kann, kanns mächtig krachen! Was ist wenn der Fremdcode die gleichen Datentypen definiert wie ich. Der Compiler meckert natürlich berechtigt rum das die doppelt definiert werden, ich hab aber keine Möglichkeit das zu ändern! Schon muss wieder umständlich über Präprozessor oder umbiegen der Includereihenfolge das geändert werden. Das kann nen Heidenspaß machen bei Projekten mit zig hundert Dateien.
    Wobei der Präprozessor genauso ein Übel wie das Include Konzept ist...

    Zum Argument, dass man gleich die Schnittstelle sieht ohne irgendwelchen Ballast:
    Ist doch gar nicht wahr. Ich kann mir die Headerdateien ansehen, sehe aber gleichzeitig außer den zur Verfügung gestellten Funktionen, noch interne Funktionen, Membervariablen, extern Verweise und was weiß ich nicht alles.

    Diese Trennung von Definition und Implementation scheint aufn erstn Blick schön zu sein, schön übersichtlich vielleicht, aber völlig unpraktikabel! Ich muss beide unabhängig voneinander pflegen und gleich halten. Vom doppelten Schreibaufwand red ich ja noch net mal.

    Mal zum Vergleich C# was meine bevorzugte Sprache ist. Dort wird ja ein anderes Konzept verfolgt, indem alles über Namespaces geht und der Kompiler sich des selbstständig aus den referenzierten Assemblies raussucht.

    Es ist wartungsfreier. Ich habe meine Implementation der Klasse in einem bestimmten Namespace und bin erledigt mit Schreibkram. Keine Definition an anderer Stelle nötig. Wenn mal Datentypen oder Strukturen definiert sind die gleich heißen, gibts keinen Knatsch wie in C, sondern kann man ja über den Namespace qualifiziert aufrufen(okay, das kann man in C++ auch - aber halt net in C).

    Ich habe im Quellcode using Direktiven die dem Compiler erstmal sagen in welchen Namespaces er nach Code ausschau hält. Dabei wird nichts texttuell ersetzt oder fest eingebunden. Kein aufgeblähter Code wie in C, wo auch Teile eingebunden werden aus Headern die ich vielleicht gar nicht wirklich benötige.

    Zu den Interfaces: Im Gegensatz zu C und C++ gibts in C# sogar explizit das Interface Konstrukt wo dann wirklich nur das Interface beschrieben ist und nichts anderes!

    Ich meine, damals hatte das Headerkonzept was, aber zu Zeiten wo sich Compiler und Linker ruhig bissle mehr Speicher gönnen dürfen, ist es veraltet und dem Konzept z.b. von C# unterlegen - da einfach fehleranfälliger.



  • Jester schrieb:

    Lustigerweise steht der Satz auch ganz alleine da, direkt am Anfang Deines Postings, nachdem Deine sämtlichen Argumente fachgerecht zerlegt wurden. Wer käme da wohl auf die Idee, Du willst Deinen Kritikern Unwissenheit vorwerfen?

    😕

    ganz am anfang
    nachdem alle argumente...

    logik ist nicht deine staerke, aber macht nix, versteh was ich schreib wie du willst, das macht dich sicher gluecklicher.


Anmelden zum Antworten