Haben Headerdateien eigentlich Vorteile?

Blue-Tiger

was ich persoenlich an Header-Dateien mag, ist dass man die gesamte Schnittstelle einer Klasse auf einen Blick sieht Das hab ich bei Java lange Zeit vermisst

Argh, sry, ich hab mich nicht genau genug ausgedrückt. Ich meinte ob das Konzept von Headerdateien Vorteile gegenüber den anderen hat. Z.B. dem von C#.

Lyrix

gogno schrieb:

Argh, sry, ich hab mich nicht genau genug ausgedrückt. Ich meinte ob das Konzept von Headerdateien Vorteile gegenüber den anderen hat. Z.B. dem von C#.

Naja prinzipiell gibt es keinen Unterschied von der "Wirkung" her. Also ist meine Meinung.

Ob du deinen Code in ne Klassendatei / DLL / Headerdatei auslagerst hat in meinen Augen keinen gravierenden Unterschied.

rüdiger

gogno schrieb:

Argh, sry, ich hab mich nicht genau genug ausgedrückt. Ich meinte ob das Konzept von Headerdateien Vorteile gegenüber den anderen hat. Z.B. dem von C#.

Der einzige Vorteil der mir einfällt (und der auf der anderen Seite auch wieder als Nachteil angesehen wird), ist der das es sich bei #include nur um eine stupide Textersetzung handelt. Deswegen kann man im Header mehr machen.

Blue-Tiger schrieb:

was ich persoenlich an Header-Dateien mag, ist dass man die gesamte Schnittstelle einer Klasse auf einen Blick sieht Das hab ich bei Java lange Zeit vermisst

Jo, schon komisch, dass Notepad das nicht anzeigen kann. Das war mal wirklich ein non-Argument.

kingruedi schrieb:

Natürlich haben Headerdateien Vorteile:

1. Ermöglichen einfache Auslagerung von Code
2. Ermöglichen Code in verschiedenen Anwendungen zu benutzen

Neuere Programmiersprachen verfolgen zwar schon etwas andere Konzepte, aber vom Prinzip her geht es um das gleiche.

Ich verstehe diese beiden Punkte nicht. Wieso kann ich ohne Header-Dateien nicht oder irgendwie schwerer diese beiden Punkte erreichen?

gogno schrieb:

Was hat man sich damals dabei gedacht? Gab es damals Vorteile die heute nicht mehr gelten?

Ein Vorteil war früher, dass es Compilerbauern die Arbeit erleichtert hat. Vom Prinzip her ist ein C-Compiler ziemlich dumm und kann es auch ruhig sein. Dank des Übersetzungsmodells mit textuellem includen von Header-Dateien braucht er das Ergebnis der include-Orgie nur von oben nach unten durchgehen und seine Symboltabelle mitführen. Wenn irgendwas kommt, was er nicht kennt, darf er gleich schreien und abbrechen und muss nicht irgendwelche Abhängigkeiten berücksichtigen und woanders danach suchen. Super Sache also.

Heute, 30 oder 40 Jahre später, haben sich die Ansprüche an die Compiler etwas gewandelt. Man möchte, dass die Compiler hochgradig optimieren, was auf Grund der getrennten Übersetzung gar nicht möglich ist. Deshalb baut man die Übersetzungseinheiten-übergreifende Optimierungslogik in den Linker ein, der dadurch ordentlich aufgeblasen wird. Jetzt hat man zwar doch keinen dummen Compiler und Linker mehr und wahrscheinlich ist nichts schwerer, als einen C++ Compiler und Linker zu bauen, aber so ist es jetzt halt.

Man möchte unglaublich intelligente IDEs, die deinen Code verstehen, die daraus Klassendiagramme erzeugen können, die dir Ergänzungen vorschlagen und alle möglichen Arten von Bezeichnern auf Knopfdruck komplett umbenennen können oder dir aus gegebenen Code-Abschnitten Methoden extrahieren. Und hier fangen Header-Dateien und includes über 20 Ebenen hinweg (mit include-guards jeweils) wirklich an zu sucken. Wahrscheinlich ist nichts schwerer, als eine intelligente IDE für C++ zu bauen, aber so ist es jetzt halt.

Artchi

Die Headerdateien finde ich ziemlich nervig. Klar, vom Konzept her wie C und C++ arbeiten ist es halt so. Aber es ist in der heutigen Zeit trotzdem nicht mehr zeitgemäß.

Meiner Meinung nach müssten die heutigen IDEs einem auch mehr unter die Arme greifen, um das Arbeiten mit den Headern zu erleichtern. Z.B. kann ich in VC++ 2003 (2005 weiß ich nicht) immer noch nicht zwischen Header und CPP springen. Das kann die Codeblocks-IDE schon, was zeigt, das es nötig ist.

Immerhin kann man in VC++ Methoden per Wizard hinzufügen, so das ich mir das Eintragen in Header und CPP spare. Wenn ich aber mal eine Funktionssignatur ändere, muß ich das wieder von Hand in beiden Dateien machen. Neeeeeervig!

In der Boost-Mailingliste meinte vor ein paar Tagen jemand, das er die Header braucht, um eine kompakte Übersicht über seine Interfaces zu haben. Die er bei einem Nur-CPP-Konzept vermissen würde. Da sage ich nur: jeder hat heute hoffentlich eine IDE die mind. das Interface in einer Baumstruktur o.ä. in kompakter Form anzeigt.

Ansonst stören mich die Header aber nicht weiter.

Artchi

Was ich mir mal überlegt habe, wie einem die IDEs wirklich helfen könnten: Warum kann ich mich nicht einfach in meiner CPP-Datei bewegen, definiere meine Methoden usw. Und nebenbei (Mutithreading rulez!) baut die IDE die passende Header-Datei zusammen. Und wenn ich kompiliere, ist für den Compiler alles da.

So in etwa stelle ich mir eine geniale C++ IDE vor. Ob der Compiler am ende doch eine Header schluckt, ist mir egal.

Vertexwahn

Was ich mir mal überlegt habe, wie einem die IDEs wirklich helfen könnten: Warum kann ich mich nicht einfach in meiner CPP-Datei bewegen, definiere meine Methoden usw. Und nebenbei (Mutithreading rulez!) baut die IDE die passende Header-Datei zusammen. Und wenn ich kompiliere, ist für den Compiler alles da.

So in etwa stelle ich mir eine geniale C++ IDE vor. Ob der Compiler am ende doch eine Header schluckt, ist mir egal.

schreib dir ein PlugIn

Optimizer schrieb:

Blue-Tiger schrieb:

was ich persoenlich an Header-Dateien mag, ist dass man die gesamte Schnittstelle einer Klasse auf einen Blick sieht Das hab ich bei Java lange Zeit vermisst

Jo, schon komisch, dass Notepad das nicht anzeigen kann. Das war mal wirklich ein non-Argument.

Natürlich kann das Notepad. Blue-Tiger wollte dauf hinaus, dass man nicht ewig durch den ganzen Code scrollen muss um alle Methoden zu sehen. Man startet nicht immer Visual Studio um nur kurz einen Blick auf eine bestimmte Schnittstelle zu werfen, sonst würde man wegen der Ladezeit nicht mehr zum coden kommen.

Optimizer schrieb:

Man möchte, dass die Compiler hochgradig optimieren, was auf Grund der getrennten Übersetzung gar nicht möglich ist.

Begründung?

Red-Tiger schrieb:

Optimizer schrieb:

Blue-Tiger schrieb:

was ich persoenlich an Header-Dateien mag, ist dass man die gesamte Schnittstelle einer Klasse auf einen Blick sieht Das hab ich bei Java lange Zeit vermisst

Jo, schon komisch, dass Notepad das nicht anzeigen kann. Das war mal wirklich ein non-Argument.

Natürlich kann das Notepad. Blue-Tiger wollte dauf hinaus, dass man nicht ewig durch den ganzen Code scrollen muss um alle Methoden zu sehen. Man startet nicht immer Visual Studio um nur kurz einen Blick auf eine bestimmte Schnittstelle zu werfen, sonst würde man wegen der Ladezeit nicht mehr zum coden kommen.

Ich starte schon immer Visual Studio kurz. Wenn du Notepad benutzt, um Quelltext zu betrachten, hast du ganz einfach was falsch gemacht. Im übrigen ist das Argument allein schon deshalb nicht so geil, weil man im Header _jede Menge_ anderen Schrott auch noch sieht außer die Schnittstelle. Und wie gesagt, es ist schon generell ein non-Argument. Ich will gar nicht den Quelltext sehen, wenn mich die Schnittstelle interessiert, da finde ich sowas schon viel besser. Wenn du "durch den ganze Code scrollen" musst, um "alle Methoden zu sehen", dann sage ich "lerne die Bedienung einer IDE deiner Wahl".

Optimizer schrieb:

Man möchte, dass die Compiler hochgradig optimieren, was auf Grund der getrennten Übersetzung gar nicht möglich ist.

Begründung?

Die Begründung ergibt sich völlig automatisch, du willst eine Begründung für etwas wie "wenn man keinen Apfel hat und auch keinen kauft, hat man auch weiterhin keinen". Zwei Module, die sich gegenseitig benutzen, aber getrennt, nichts voneinander wissend erstellt werden und die bei der Übersetzung u.U. die Implementierung auch gar nicht kennen, können nicht hochoptimiert sein. Erst beim Linken können Dinge wie Inlining usw. wirklich gut stattfinden, weshalb man den Linker wieder aufbläht. Stand aber fast so auch schon ein, zwei Sätze später.

Blue-Tiger

Optimizer schrieb:

Blue-Tiger schrieb:

was ich persoenlich an Header-Dateien mag, ist dass man die gesamte Schnittstelle einer Klasse auf einen Blick sieht Das hab ich bei Java lange Zeit vermisst

Jo, schon komisch, dass Notepad das nicht anzeigen kann. Das war mal wirklich ein non-Argument.

Mag sein dass ich da unflexibel bin, aber ich find Header-Dateien in der Hinsicht irgendwie uebersichtlicher als die Methodenauflistungen, die mir IDEs anbieten. Ich geb zu bei tiefen Klassenhierarchien ist eine Header-Datei bei weitem nicht so informativ wie das, was mir in der IDE angeboten wird. Trotzdem, ich persoenlich (<< subtiler Hinweis, den du anscheinend beim ersten mal nicht mitbekommen hast) komm idR mit Header-Files besser zurecht als mit "Class Browsern" oder aehnlichem.

energyzer

Ich kann mit dem gezeigten Objektbrowser zwar auch nicht viel anfangen, aber
trotz allem reicht mir die Übersichtlichkeit der (z.B.) C#-Files vollkommen
aus. Wenn die Klassen klein sind (was sie ja sein sollten ), man eine IDE
mit IntelliSense hat (wie heißt das bei der Konkurrenz ) und die
Möglichkeit der IDEs nutzt, Bereiche zu gruppieren hat man eine genauso gute
Übersicht, wie bei Header-Files.

Auf großen Monitoren, wo man den Objektbrowser ständig einblenden kann, ist
dieser sicher auch nützlich...

energyzer schrieb:

wie heißt das bei der Konkurrenz

Das ist unterschiedlich. Microsoft fasst unter dem Begriff "IntelliSense" alles zusammen, Dinge die bei der Konkurrenz code completion, parameter help, quick info, code templates ("implement interface..." usw. heißen.

SG1

Wie jetzt? Sie haben dafuer nur EIN buzzword???

Optimizer schrieb:

Die Begründung ergibt sich völlig automatisch, du willst eine Begründung für etwas wie "wenn man keinen Apfel hat und auch keinen kauft, hat man auch weiterhin keinen". Zwei Module, die sich gegenseitig benutzen, aber getrennt, nichts voneinander wissend erstellt werden und die bei der Übersetzung u.U. die Implementierung auch gar nicht kennen, können nicht hochoptimiert sein. Erst beim Linken können Dinge wie Inlining usw. wirklich gut stattfinden, weshalb man den Linker wieder aufbläht. Stand aber fast so auch schon ein, zwei Sätze später.

Blödsinn.

daHa

wenn man das konzept header datein nicht verstanden hat weis man nicht wozu sie gut sind, das ist klar.

das das konzept nicht zeitgemaess sein soll ist bloedsinn.

das man eine zeitlang damit arbeiten muss um dieses konzept zu verstehen ist auch klar.

hat man das nicht, und java nochdazu fuer das mass aller dinge haelt, dann soll man wenigstens keinen bloedsinn reden.

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.
(
wobei, nicht das ich IDEs nicht mag, es kostet mich zB gemau einen klick um aus einem hxx wo der ganze "private schrott" vorhanden ist eine interface hxx zu erstellen die dann nur mehr das beinhaltet was fuer den benutzer relevant ist.
)

Artchi

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?

Der Vororteinsatz mitohne IDE ist doch ein Argument!

Vertexwahn

@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

daHa

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.