Haben Headerdateien eigentlich Vorteile?
-
@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.
-
Talla schrieb:
Die Includereihenfolge muss fest stehen
hin und wieder, ganz ganz selten, ja, allerdings ist das die ausnahem, vorallem in C, C++ mit namespaces vermindern die von dir beschreibene problematik noch mehr.
is ja nicht so das einem das taeglich und immer wieder aufs neue aergert.
in anderen sprachen machen manche sachen auch aerger die es in wieder andern sprachen so eigentlich keinen aerger machen koenne weil da was anders is...
Talla schrieb:
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.doch, ist so, und eine IDE kann dich bei der erzeugung unterstuetzen, bei mir zB rechtsklick, schnittstelle extrahieren, fertig.
so man das will, manchmal will man auch mehr info weitergeben.
Talla schrieb:
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.
so schwierig und so viel mehraufwand ist es nicht, wenn man sich ein bissl eingearbeitet hat.
fuer einsteiger ist es event gewoehnugsbeduerftig und es dauert ein bissl bis es automatisiert ist.Talla schrieb:
Wobei der Präprozessor genauso ein Übel wie das Include Konzept ist...
aber er duerfte einigen abgehen da es java projekte fuer preprozessor nachbildungen gibt.
wie auch immer, anscheinend kann der preprozessor was, das duerfte dir aber nicht abgehen.
Talla schrieb:
Mal zum Vergleich C# was meine bevorzugte Sprache ist.
C# hat wirklich interessante ansaetze, lernt von anderen und probierts besser zu machen, bringt das auch zusammen.
und laesst einem freiheiten die andere sprache verhindern. (boeser seitenhieb gegen java ist das, die diskusion soll ja nicht einschlafen)die header fehln mir halt, aber das is gewoehung
im ernst, c# taet ich uU gern fuer manche aufgaben verwenden, wenns nicht einen nachteil haett, es lauft nicht auf den plattformen auf denen ich arbeite, und mit mono is noch einiges offen bzw noch nicht geklaehrt genug das ich ernsthafte projekte damit mach.
die politischen bzw religioesen gruende lass ich aus, sonst geht das happy verbaldraufdresch das ganze WE weiter.
-
Mal angenommen ich habe eine Library entwickelt, und moechte nicht dass die Implementation bekannt wird. In C++ kein Problem, ich liefere die kompilierte *.lib und die passende Header-Datei aus. Mal von Reverse-Engineering abgesehen (was bei komplizierteren Libs bald mal sehr schwierig ist) denk ich ist meine Implemetierung relativ geheim (kann ja Proxies verwenden um "private"-Dinger auszublenden, wenn ichs wirklich noetig hab).
Wie wird so ein Problem mit anderen Sprachen geloest?
-
Obfuscator
-
Blue-Tiger schrieb:
Mal angenommen ich habe eine Library entwickelt, und moechte nicht dass die Implementation bekannt wird. In C++ kein Problem, ich liefere die kompilierte *.lib und die passende Header-Datei aus.
Bäääääng und hast schon mehr über die Implementierung verraten als dir lieb ist. Können wir uns nicht wenigstens mal darauf einigen, dass ein Header _nicht nur_ die Schnittstelle verrät? Das ist immer das tolle Standard-Argument, ist aber einfach falsch.
Wie wird so ein Problem mit anderen Sprachen geloest?
In Sprachen mit just-in-time linking gibt's das Problem nicht. Ich kann die "fertig" compilierten Klassen in einer DLL bereitstellen, du kannst sie benutzen, weil die .Net-DLL (nimm alternativ ein Java .class file) die notwendigen Metadaten enthält. Den Sourcecode meiner Klassen kriegt keiner mehr zu sehen.
Man kann auch noch stärker trennen. Ich liefer die fertig compilierte DLL mit der Implementierung aus. Außerdem gibt's noch ne weitere DLL, die nur Interfaces enthält. Die Implementierungs-DLL und der Client-Code beziehen sich auf diese Interfaces und die Interfaces verraten gar nichts.
Ist übrigens auch ein typisches Remoting-Szenario. Der Server bietet Services über die Interfaces, derjenige, der einen Client schreibt, kriegt nur die Interfaces-DLL und kann alles nutzen. Der Client ist in diesem Fall sogar physikalisch von der Implementierung getrennt.
-
Optimizer schrieb:
Den Sourcecode meiner Klassen kriegt keiner mehr zu sehen.
zum glück gibts für .net und java keine fähigen decompiler
-
... schrieb:
Optimizer schrieb:
Den Sourcecode meiner Klassen kriegt keiner mehr zu sehen.
zum glück gibts für .net und java keine fähigen decompiler
Zum Glück hat das jetzt gar nichts mit der Sprache zu tun.
Wenn man Bytecode so optimieren würde wie fertig compilierten native code, wäre er nahezu genauso schwer zu decompilieren. Es geht hier nur um das System, wie man Schnittstellen verbreitet und das decompilieren hat zunächst mal gar nichts damit zu tun und es wird auch nicht durch dieses System begünstigt. Die ach so tollen .lib files lassen sich übrigens auch leicht decompilieren, so wie alles, was noch nicht optimiert compiliert ist. Jetzt ist noch nicht mal klar, ob es überhaupt darum geht, den Quelltext zu verbergen, oder einfach nur eine gute Kapselung und Software-Design zu erreichen.
-
daHa schrieb:
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?
logik ist nicht deine staerke, aber macht nix, versteh was ich schreib wie du willst, das macht dich sicher gluecklicher.
Welch Ironie. Lass es besser bleiben - bis jetzt hast du außer Standard-Blabla nicht einen stichhaltigen Vorteil von Headern genannt.
Ich finde Header-Files auf jeden Fall nervig und antiquiert (alleine diese Include Guards...). Und das Argument der Trennung von Interface und Implementierung ist oft auch nur theoretischer Natur. In vielen großen Projekten habe ich gesehen, dass aus Geschwindigkeitsgründen die Methoden Definitionen usw. IM Header stehen. Klar kann man jetzt wieder einwerfen es gibt ja das Keyword inline. Aber in der Praxis siehts nun mal so aus, das viele einfach das Zeug mit in den Header klatschen.
Die Struktur neuer Sprachen finde ich wesentlich angenehmer. Man schreibt einfach seinen Code und um die ganzen Abhängigkeiten kümmert sich der Compiler/Linker. Und zur Einsicht in die Interfaces habe ich die IDE und/oder Hilfedateien.