Haben Headerdateien eigentlich Vorteile?
-
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.
-
Talla,
mir is gestern nach dem ich den pc abgedreht hab noch eingefallen, konrollier mal deine include guards, event is desswegen die reihenfolge beim include ein prob fuer dich.
in der regel sollt dieses prob nicht exestieren, hatte einmal so was, denk aber das es damals ein fehler in den guards war.ansosnts bin ich der ansicht:
nur weil neue sprachen in manchen bereichen neue wege gehen, es is nicht so das diese wege per deffinition tatsaechlich ueberlegen oder elegnater (elegant == geschmack) sind.manchmal sind sie es (traurig wenn nicht, weil wozu sonst neue sprachen), manchmal sind sie nur anders (und tragen dann das label moderner )
was mir weniger gefaellt, das die propaganda der jeweiligen komerzfraktion hinter diesen sprachen.
hier wird halb information mit lari fari vermischt, sachen werden konstruiert die unter XY sprache so nicht gehn, ignoriert wird das man sie in XY anders loest, bzw konstrukte werden gebaut um probleme in sprache XY aufzuzeigen die in der realtiaet so quasi nie vorkommen.
rauskommen dabei irgendwelche hablseidenen argumentationen die gespickt sind mit technischem halbwissen bzw derart verdrehtem bloesinn das es reicht um bei diversen veranstaltungen lustige sprueche zu klopfen, aber einer ueberpruefung in der realitaet so nicht standhaelt, oder geschmacksentscheidungen werden zu technischen erklaehrungen, oder ....
das ist eigentlich schade
-
Haben Headerdateien eigentlich Vorteile?
Nein.
-
Optimizer schrieb:
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.
Schon mal was von Proxies gehoert? Header-Files bieten mir sehr wohl die Moeglichkeit meine Implementierung verstecken, wenn ich das will.
Optimizer schrieb:
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 aber 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.
Ich muss mich jetzt mal nur auf Java beschraenken, .NET kenn ich leider nicht:
Remoting-Szenario ist mit Sicherheit ein guter Weg um die Implementierung zu verstecken,nur ist das nur sehr beschraenkt moeglich. Nicht jeder PC haengt im Netz, und nicht jeder Prozessor steckt in einem PC.
Aber selbst wenn: Mal angenommen ich versteck meine Implementierung hinter RMI, dann geb ich dem Benutzer immer noch ein Interface, das er verwenden soll. Aber inwiefern unterschiedet ein Interface von einem Headerfile in diesem Fall von einem Headerfile (abgesehen davon, dass es keine verschraenkten Includes geben kann, was in meinen Augen kein Problem ist)?DISCLAIMER: ich will nicht auf Teufel komm raus Header-Files als C++ groesste Staerke verteidigen, aber ich seh nach wie vor deren grossen Nachteil nicht ein.
-
Blue-Tiger schrieb:
Optimizer schrieb:
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.
Schon mal was von Proxies gehoert? Header-Files bieten mir sehr wohl die Moeglichkeit meine Implementierung verstecken, wenn ich das will.
Du willst mir jetzt aber nicht erzählen, dass das genauso gut gelöst ist, wie wenn man keine Header-Files brauchen würde, oder? Wenn ich zusätzlichen Aufwand betreiben muss mit zusätzlicher Indirektion und statt an zwei Stellen an 3 oder 4 was ändern muss, dann spricht das wohl wirklich nicht für Header-Files.
Optimizer schrieb:
Remoting-Szenario ist mit Sicherheit ein guter Weg um die Implementierung zu verstecken,nur ist das nur sehr beschraenkt moeglich. Nicht jeder PC haengt im Netz, und nicht jeder Prozessor steckt in einem PC.
Klar, das ist der Idealfall. Im "Normalfall", wenn ich wirklich die implementierende Klasse mit ausliefere, kommt der Benutzer aber trotzdem nicht an den Source. Ein .class file hat den Header einfach mit eingebaut und mit dem Rest kann man nichts anfangen. Die VM selbst verhindert zur Link-Zeit, dass du private Datenelemente ansprichst.
Aber selbst wenn: Mal angenommen ich versteck meine Implementierung hinter RMI, dann geb ich dem Benutzer immer noch ein Interface, das er verwenden soll. Aber inwiefern unterschiedet ein Interface von einem Headerfile in diesem Fall von einem Headerfile (abgesehen davon, dass es keine verschraenkten Includes geben kann, was in meinen Augen kein Problem ist)?
Header-Files haben eigentlich fast nur Nachteile gegenüber Interfaces oder den Metadaten von .class Files (lass ma mal die Metadaten, Interfaces sind eigentlich ein Sprachmittel und habe ich nur erwähnt, um den Zugriff auf libs zu beschreiben). Sie verraten mehr über die Implementierung, wenn ich nicht zusätzlichen Aufwand betreibe, um diese zu verstecken. Die include-Reihenfolge kann wichtig sein (wie scheiße ist das?!). Wenn jemand ein Depp ist, macht er in den Header Makros, using-Direktiven oder sonstwas rein, was mit meinem Quellcode dann in Konflikt steht. Wie schlecht ist das textuelle includen eigentlich?
Die Liste ist wirklich endlos - kann man nicht einfach mal einsehen, dass es ein Konzept aus der Computer-Steinzeit ist und dass es suckt? Ich flame jetzt wirklich nicht rum nach dem Motto "C++ ist scheiße, Java ist geil", aber man kann doch wirklich mal einsehen, dass das Übersetzungsmodell mit allem, was dazu gehört, einschließlich Headerfiles, einschließlich endlosen Übersetzungszeiten auf Grund mangelnder Schnittstellenprüfung unglaublich schlecht ist. Und die riesigen Compilerfarmen mit endlos langen Übersetzungszeiten geben mir in diesem Punkt sicherlich auch recht. Ich habe noch nie gesehen, dass man Tage braucht, um ein Java-Programm zu compilieren.