Haben Headerdateien eigentlich Vorteile?
-
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.
-
In technischer Hinsicht:
- dass ein Header das Interface zeigt, ist nur ein netter Nebeneffekt. Der
Header ist eigentlich für den Compiler da: der muss die Definition des Klasse
(oder des pod-typen) kennen bevor er sie verwendet: Das sind die , die die
Größe des Objekts bestimmen. Die Größe des Objekts
ist nötig um das Objekte auf dem Stack ablegen zu können.- 'moderne' sprachen wie Java, C# etc. müssen die Definition einer Klasse nicht
kennen (nur die Deklation: wie heißt die Klasse und welche Funktionen hat
sie). Dafür nehmen sie aber eine Einschränkung in Kauf: Die Objekte können nur
auf dem Heap angelegt werden. Damit haben die Objekte auf dem Stack nämlich
immer eine feste Größe: die eines Zeigers.
Das entspricht etwa dem was man in c++ mit forward-Deklarationen von Klassen
macht (nur Fehlen hier dann die Funktionen, die aber eigentlich zur
Deklaration nicht zur Definition gehören).Fazit 1:
Das Header-Konzept ist in C++ inhärent notwendig um Sprachidiome zu ermöglichen die es in anderen Sprachen so nicht gibt:- Objekte auf dem Stack. Das hat weitere folgen:
-- 'do it like the ints': In c++ kann man klassen schreiben, die sich wie
eingebaute Typen verhalten (kopieren etc.)
Im Gegansatz: Wrapper-Klassen in Java: hier verhalten sich eingebaute
typen wie Klassen.
-- automatische Auslösung des dtors (= deterministisches Aufräumverhalten)- Durch die Header werden aber auch Deklaration (Name der Klassen und Signatur
der Methoden) und Definition vermischt.Aus Sicht des täglichen Header-schreibers:
- Header sind blöd, weil man viel redundant machen muss
- Die mir bekannten class-browser kommen aber trotzdem in Sachen
Übersichtlichkeit nicht an den (gut geschriebenen) Header ran, weil z.B.
die Kommentare fehlen (oder erst kommen, wenn ich den Mauszeiger richtig
patziere. Das Problem löst sich sich aber durch Dokumentationsgeneratoren
(doxygen oder java-doc)- Das header-konzept führt zu den irrsinnig langen compilezeiten (v.a. in Verbindung
mit templates, aber anderes Thema). Vorkompilierte Header schaffen nur teilweise
abhilfe (und sind selbst ein komplexes IDE und compiler-abhängiges Thema).- Will ich deklaration und definition sauber trennen muss ich zu pimpl-Idiom o.ä.
greifen. Das wiederum ist aber auf eine so dumpf-blöde Art wartungsaufwendig,
dass ich das wirklich nur da mache, wo ich mich ganz bewusst dafür entscheide
dass da eine saubere Schnittstelle nötig ist (selbige ist aber eigentlich bei
jeder Klasse notwendig).Fazit 2 (oder was ich nicht verstehe)
- Ist es wirlich so schwer auch mit headern ne anständige tool-unterstützung
hinzukriegen (z.B Header und cpp synchron halten)?- Kann man das mit dem compilezeiten nicht in Griff kriegen, ohne dass sich da
der Entwickler ewig Gedanken um die vorkompilierten Header machen muss (gleiche
Reihenfolge etc.).- Hab mal gehört dass VisualAge C++ (IBM) das ganze ziehmlich gut in Griff hatte,
weil es den Code auf Datenbank-Basis hatte statt auf file-Basis.- Das Argument 'was ist, wenn Du keine Anständige Entwicklungsumgebung und nur
Notepad zur Verfügung hast', zieht nicht aus zwei gründen:
-- Privat-Bereich: Anständige C++-IDEs sind vielleicht teuer aber der Java-Bereich
zeigt, dass das eigentlich nicht so sein muss.
-- Professionell: Dass man keine Entwicklungsumgebung hat, ist wohl eher ein
Spezialfall. Und wenn die (imaginär) gemergte Version von cpp und h-File dann
wirklich zu unübersichtlich ist, gibts immer noch die Dokumentationsgeneratoren.- Wenn mich nicht jeder Kollege dann blöd anschauen würde, und es nicht völlig
unübersichtlich in Verbindung mit vorhandenem Code wäre, hätt ich mir schon längst
einen Satz von Makros zusammengestellt, mit dessen Hilfe mir der präprozessor
aus meiner einzigen Datei header und cpp-File erstellen würde. Ich schätz da gibts
aber noch Probleme, die ich mir nicht überlegt hab, weil sonst hätten das bestimmt
schon mehr Leute gemacht.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
Will man die inline-Funktion in mehreren Modulen verwenden, muss sie ja wohl auch im Header stehen
Z.B. kann ich in VC++ 2003 (2005 weiß ich nicht) immer noch nicht zwischen Header und CPP springen.
In VC++ 2005: vom cpp in den Header aber nicht umgekehrt ...
Das sind Punkte, wo man sich ans Hirn langMal 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.
Aha, aber nur wenn Du zufällig weißt, auf welchem compiler dein Kunde sein Projektemit welchen Compilereinstellungen compilieren will. Sonst kommt es zu Problemen zur Übersetzungzeit (compiler A versteht die Lib von Compiler B nicht) bis zu solchen zur Laufzeit (dein Proggie stürzt mittendrin ab, weil das was Compiler A in der Applikation des Kunden mit dem Header macht nicht dem entspricht was derselbe Compiler A mit anderen Compilereinstellungen mit dem Header gemacht hat, als Du die lib übersetzt hast (stichwort Aufrufkonvetion, multithreaded oder gar cell-padding). Das sind übrigens die Probleme einer Lib mit C-Schnittstelle. In C++ kommen diverse dazu (z.B. namemangeling).
Die einzige Lösung, die ich kenne (wenn man nicht den code ausliefern will): ne dll und code, der diese dll dynamisch lädt (behebt aber auch nicht alle o.g. Probleme).
-
<flame opt="on" />
Könnte daran liegen, dass genau diese Anwendungen aus diversen Gründen nicht in Java geschrieben werden.
<flame opt="off" />Ich finde es einfach nur Schick, dass man die Deklaration von der Implementierung trennen kann. Ist aber Geschmacksache, wie ich weiter oben schon geschrieben habe.
Wenn ich mir irgendwo Sources runterlade, dann kann ich mir relativ schnell den Aufbau ansehen, weiß, welche Klassen welche Methoden haben, etc. Ich arbeite z.B. viel mit Ultraedit und auch Java habe ich mit Ultraedit programmiert, also ohne IDE. Ich habe zwar nur kleine Klassen an der Uni geschrieben, aber es hat mich halt gestört, dass ich nicht alle Methoden der Klasse auf einem Blick sehe/sehen kann (Folding mal ausgenommen). Ich weiß, mit ner IDE sieht das schon wieder anders aus.
Wird wohl immer Geschmacksache bleiben, aber wir haben ja zum Glück die Wahl (wenn der Arbeitgeber und/oder Kunde nichts vorschreibt) womit wir programmieren.
-
Ich habe zwar nur kleine Klassen an der Uni geschrieben
Ich bin eigentlich der Meinung, dass man in C++ schneller gut funktionierenden Programmen kommen kann weil man viel besser als z.B. in Java ausdrücken kann, was man will (stichwort const-correctness und Typsicherheit).
Ich entwickle jetzt allerdings das erste mal an einem größeren Java-Projekt und ich muss sagen, ich bin hin und weg, wie viel Zeit man durch ne Entwicklungsumgebung wie eclipse spart:
- Umbenennen von Klassen, Variablen, Methoden
- keine Zwangspausen mit warten auf den compiler: was nicht rot unterringelt ist
ist syntaktisch korrekt (dabei arbeite ich in VC++ zwischenzeitlich mit Visual
Assist: Da können noch ne Menge fehler drin sein, wenn er nix mehr
unterringelt)
- Volle Integration von Unit-Testing in die IDE
- Aber das ist alles eigentlich off-topic.
-
kartoffelsack schrieb:
Das Header-Konzept ist in C++ inhärent notwendig um Sprachidiome zu ermöglichen die es in anderen Sprachen so nicht gibt:
- Objekte auf dem Stack. [...]
In C# kannst du auch Instanzen von Klassen auf dem Stack allokieren, und Instanzen von structs werden sogar immer auf dem Stack allokiert. Der technische Unterschied ist einfach das Linking zur Laufzeit. Wenn eine Methode zum ersten mal aufgerufen und JIT-compiliert wird, kann der JIT-compiler sich ohne Probleme die Klassendefinition ansehen und die Größe erkennen. Die ganze Klassendefinition steht dem JITer zur Verfügung und das, was in C++ ein Header ist, braucht man schlicht nicht, weil die statischen Compiler die Größe der Typen nicht kennen müssen (denn sie erzeugen nicht den Maschinencode).
-
auch durch das staendige wiederhohlen von halbwahrheiten und halbragen zeug werden diese nicht richtiger bzw werden zu brauchbaren nachvollziehbaren argumenten
Optimizer schrieb:
Sie verraten mehr über die Implementierung, wenn ich nicht zusätzlichen Aufwand betreibe, um diese zu verstecken.
wie aufwendig es ist hab ich beschrieben, laesst du das nicht gelten weil IDE unterstuetzt?
Optimizer schrieb:
Die include-Reihenfolge kann wichtig sein (wie scheiße ist das?!).
ich ersuche dich um praxisrelevatne beispiele die die includereihenfolge zum problem machen.
sachen ala
Optimizer schrieb:
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?
gelten nicht, wenn man problem code erbt, dann ist das sprachunabhaenig ein problem.
ich bin sicher, ein depp kann auch in java c# sonstigen so programmieren das es fuer andere die damit arbeiten muessen zum problem wird.
Optimizer schrieb:
Die Liste ist wirklich endlos - kann man nicht einfach mal einsehen, dass es ein Konzept aus der Computer-Steinzeit ist und dass es suckt?
die endlose liste seh ich nicht.
header ham lange nicht alle nachteile die du ihnen unterstellst, und in der realtiaet werden mit diesen mitteln noch sehr brauchbare sachen gemacht.
lauter deppen die noch nicht auf die wahre religion umgestiegen sind?Optimizer schrieb:
Ich flame jetzt wirklich nicht rum nach dem Motto "C++ ist scheiße, Java ist geil"
aso?
Optimizer schrieb:
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.
wie praxis und ergebnis relevant sind die uebersetzungszeiten?
wuerdest du mir bitte den faktor nennen um welchen java c# oder sonstige sachen schneller kompilieren?
am besten an hand gleichwertiger programme, einen kernel mit hello word vergleich is witzlos.und sind scriptsprachen besser weil sie noch schneller ausfuehrbare sachen bringen, ganz ohne exta compiler?
und wuerdest du mir bitte beispiele nennen wofuer die riesigen compilerframen gebraucht werden,
und wenn dir ein Bsp eingefallen ist wofuer comilerframen gebraucht werden, wo sind die moderneren loesungen sind mit denen man diese framen abschaffen kann und warum wurde das nicht gemacht?
-
wie aufwendig es ist hab ich beschrieben, laesst du das nicht gelten weil IDE unterstuetzt?
Es geht hier um die angesprochenen Proxies und ich kenne keine IDE, die das für mich generiert. Überhaupt kenne ich nicht viele IDEs, die mir die Arbeit mit Headern nennenswert abnehmen. Und überhaupt sind jetzt Proxies immer noch nicht geil, sondern nur was hässliches, was ich brauche, weil das Übersetzungsmodell halt doch nicht so toll ist.
ich ersuche dich um praxisrelevatne beispiele die die includereihenfolge zum problem machen.
Finde selber was. Dieses Problem hatte jeder schon einmal. Es sagt keiner, dass es nicht lösbar ist, aber es ist scheiße.
Optimizer schrieb:
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?
gelten nicht, wenn man problem code erbt, dann ist das sprachunabhaenig ein problem.
ich bin sicher, ein depp kann auch in java c# sonstigen so programmieren das es fuer andere die damit arbeiten muessen zum problem wird.
Dann dreh es halt um und geh von fähigen Programmierern aus. Wie schlecht ist es, in Headern nicht using benutzen zu können? Wie schlecht ist es, ständig voll qualifizierte Namen auszuschreiben, die zusammen mit Templates dann alleine schon eine Zeile füllen? Jetzt sagst du einfach "schlechte Programmierer zählen nicht", hast aber nicht näher ausgeführt, was passiert, wenn die Programmierer die Problematik kennen. Oder wolltest du darauf vielleicht nicht eingehen? Ist es doch nicht so vorteilhaft, wenn man vorgeschrieben bekommt, man darf dieses und jenes nicht benutzen und muss stattdessen jedesmal template<class IndexType> typename IndexType::const_iterator (man beachte, dies ist ein sehr harmloser templatisierter typ) ausschreiben? Ach was red ich, du wirst eh einfach nur sagen "das ist nicht schlimm", anscheinend interessiert dich nicht, wenn es besser geht.
wie praxis und ergebnis relevant sind die uebersetzungszeiten?
Sehr. Große Programme wie kommerzielle Spiele und Betriebssysteme oder nur Kernels brauchen Stunden und Tage, um übersetzt zu werden.
wuerdest du mir bitte den faktor nennen um welchen java c# oder sonstige sachen schneller kompilieren?
am besten an hand gleichwertiger programme, einen kernel mit hello word vergleich is witzlos.Hier geht es nicht um einen konstanten Faktor. Bei allen modernen Übersetzungsmodellen bist du um Größenordnungen schneller. Dass du solche Fragen stellst, zeigt nur eins: Du weißt es einfach nicht, willst es nicht wahrhaben, glaubst es nicht, es ist aber so. Jeder, der irgendwann schon einmal etwas nur mittelgroßes geschrieben hat, merkt das sofort.
und sind scriptsprachen besser weil sie noch schneller ausfuehrbare sachen bringen, ganz ohne exta compiler?
Was hat das damit zu tun?
und wuerdest du mir bitte beispiele nennen wofuer die riesigen compilerframen gebraucht werden
Nein, mach selber. Sourceforge bietet dir ne Compilerfarm, wenn du mal eine brauchst.
auch durch das staendige wiederhohlen von halbwahrheiten und halbragen zeug werden diese nicht richtiger bzw werden zu brauchbaren nachvollziehbaren argumenten
Klar, es ist nicht schlecht, wenn ich mich um Firlefanz kümmern muss, anstatt programmieren zu können. Klar, es ist nicht schlecht, wenn ein Programm Tage zum übersetzen braucht und man ganze Compilerfarmen hinstellen muss. Du bist jetzt gerade so weit, dass du mit Header-Dateien zurecht kommst und daher mit einigen Nachteilen leben kannst. Fälschlicherweise stellst du das aber so hin, als gäbe es diese Nachteile nicht oder als wären sie nicht relevant. Was in den letzten Jahrzehnten nach der Entwicklung von C++ in Forschung über Compilerbau gesteckt wurde, weißt du einfach besser und kannst dank deiner endlosen Kompetenz Fakten als Halbwahrheiten hinstellen.
Wenn du dich mal mit dem Compilerbau befasst, wirst du auch mal feststellen, dass das Konzept der Header-Dateien seit 20 Jahren veraltet ist und nicht als tolle Interface-Darstellungshilfe der Programmierer entworfen wurde, sondern eine technische Notwendigkeit des Übersetzungsmodells war. Und dass diese Konzept praktisch nirgendwo mehr verfolgt wird. Für das, dass du wirklich keine nennenswerte Ahnung vom Thema hast, redest mit einer Ausdauer dagegen an, dass einem schlecht werden kann.
-
optimizer, ich nehm zur kentniss das viele deiner hinweise und argumente von dir selbst nicht durch praxisrelevante beispiele belegbar sind, wiedermal.
halbgarer mist den du von dir gibst, die meisten bsp die du bringst haben bestenfalls theoretische berechtigung, praktisch gleich null, fuers taegliche arbeiten irrelevant.
marketingmist und halbgare propaganda zum quatrat.
du glaubst ja sogar wirklich das man fuers taegliche arbeiten compilerfarmen braucht, und das kernel compilieren tage dauert.
und das einem das tag fuer tag die zeit stiehlt.dein einziges argument is neuer==besser, und daraus folgerst du das alles bisher gewesene alter scheiss ist.
welch zwingende logik, die du zwar nicht argumentieren kannst, ausser mit halbgaren geschwafel, aber das stoert dich nicht.und nur preventiv, um unterstellungen vorzubeugen, ich schreib nicht das header ueberlegen sind, bzw module die symbolinfos einbinden mist sind.
ich relativer nur den mist den du von dir gibst, und anhand dessen du konzepte die nicht deiner bevorzugten religion folgen die lebensberechtigung absprechen willst bzw als scheisse bezeichnest.
und die dir helfen koennten die dir, von dir, gestellte frage zu beantworten warum noch nicht alle welt die alten konzepte verteufelt und der von dir bevorzugten religion folgt.
-
Hier ist keine Religion im Spiel. Seit C haben sich die Übesetzungsmodelle weiterentwickelt und mehr sage ich nicht.
Ich verteufel gar nichts, sondern appelliere nur daran, einzusehen, dass ein Übersetzungsmodell mit Header-Dateien aus heutiger Sicht veraltet und ungut ist. Das wird aber nicht eingesehen, stattdessen werden sie als etwas tolles und praktisches zur Übersichtlichkeit dargestellt.
Dass der Linux-Kernel Tage zum Übersetzen braucht, habe ich nicht behauptet. Wohl aber eine Zeit, die alles andere als genehm ist und wenn du eine komplette Distribution baust, bist du mit vielen Stunden dabei. Sowas gäbe es bei modernen Übersetzungsmodellen nicht, ob ganzes Betriebssystem hin oder her. Um den Unterschied zu begreifen, braucht man Ahnung vom Compilerbau, die du nicht hast. Mit Sicherheit hast du auch entsprechende Vorlesungen nie besucht oder nur darin geschlafen.
Header-Dateien sind aus der Mode, genauso wie du. Da dein letztes Posting nur noch fiese und unhaltbare Behauptungen und Unterstellungen enthält, steige ich hiermit aus.