C++ ist Müll!
-
HumeSikkins schrieb:
Aber man kann natürlich auch gleich wieder krampfhaft disktutieren wollen.
War doch keine Diskussion, wusste nur niemand dass man da überhaupt was unterscheiden kann
-
@Hume war doch nicht böse gemeint.
Wie dem auch sei, thx für die Antwort. Erneut eine Wissenslücke gefüllt
thx
-
@DrGreenthumb und Knuddlbaer
Ihr wart nicht gemeint. Es ging mir nur um dieses "für mich ist das aber ein Elefant".
-
abgesehn davon sind die gar nich "notwendig"
je nach design gehts auch ohne
-
also c++ ist ja im prinzip schon in ordnung, was mich aber zum beispiel stört sind:
-header dateien
-die Notwendigkeit von Funktions Prototypen
-ein garbage-collector wär auch nicht schlechtgibts da nicht was besseres?
Guck dich doch einfach um. Viele Sprachen arbeiten mit anderen Modulkonzepten, die ohne Header auskommen und GCs haben.
-
Was ist so schlimm an Headerdateien? Man kann auch (wenn man das besser findet) seine Klassen im Java-Style anlegen. Ich finde die Unterscheidung in cpp- und h-Files gerade vorteilhaft.
-
Ich überhauptnicht.
Trennung von Schnittstelle und Implementierung ist OK, aber warum in verschiedenen Dateien (und dann auch noch inkonsequent wegen Templates?)
Und die Synthax fürs außerhalb der Klasse definieren ist auch mehr als dämlich.
-
MaSTaH schrieb:
Was ist so schlimm an Headerdateien?
Dass man an 2 Stellen das gleiche schreiben und in Übereinstimmung halten muss.
Man kann auch (wenn man das besser findet) seine Klassen im Java-Style anlegen.
Nein. Wenn du alles im Header implementierst, werden alle Member inline, du verzichtest auf den Vorteil der getrennten Übersetzung und steigerst die Übersetzungszeit ins Unermeßliche.
Modern wäre IMHO, wenn der Compiler die Header automatisch generiert. Das muss nicht unbedingt in Quellcode-Form sein, vielleicht auch nur als Eintrag in irgendeiner Deklarationsdatenbank. Die würde er jeweils updaten, wenn die Implementierungsdatei sich so verändert hat, dass die Schnittstelle nicht mehr stimmt. Das hätte u.a. auch den Vorteil, dass man private, nichtvirtuelle Memberfunktionen hinzufügen könnte, ohne dass alle abhängigen Implementierungsdateien neu übersetzt werden müssen.
-
Bashar schrieb:
MaSTaH schrieb:
Was ist so schlimm an Headerdateien?
Dass man an 2 Stellen das gleiche schreiben und in Übereinstimmung halten muss.
ACK
Bashar schrieb:
Man kann auch (wenn man das besser findet) seine Klassen im Java-Style anlegen.
Nein. Wenn du alles im Header implementierst, werden alle Member inline, du verzichtest auf den Vorteil der getrennten Übersetzung und steigerst die Übersetzungszeit ins Unermeßliche.
Ich sag ja nicht dass es toll ist oder irgendwelche Vorteile bringt. Die Übersetzungszeit dürfte jemandem, der so etwas macht spätestens bei einem größeren Projekt zum Verhängnis werden.
-
MaSTaH schrieb:
Ich sag ja nicht dass es toll ist oder irgendwelche Vorteile bringt.
Du hast es als Alternative für Leute angeführt, die die Trennung in Header und Implementation angeführt, oder? Jedenfalls lese ich das in dein Posting hinein.
Mich würde jedenfalls mal interessieren, warum die dese Trennung für vorteilhaft hältst.
-
Bashar schrieb:
MaSTaH schrieb:
Ich sag ja nicht dass es toll ist oder irgendwelche Vorteile bringt.
Du hast es als Alternative für Leute angeführt, die die Trennung in Header und Implementation angeführt, oder? Jedenfalls lese ich das in dein Posting hinein.
Es sollte eher trotzig rüber kommen
.Bashar schrieb:
Mich würde jedenfalls mal interessieren, warum die dese Trennung für vorteilhaft hältst.
- Wenn es um Bibilotheken geht ist die Trennung unverzichtbar, es sei denn es gäbe eine Möglichkeit eine Schnittstellendatei generieren zu lassen.
- Wenn man (noch) keine Doku generiert hat sieht man schnell welche Funktionen in der Klasse implementiert sind.
- Vielleicht bin ich es einfach gewohnt... <- scheiß Argument, ich weiß
Das alles ließe sich auch mit einer intelligenteren IDE lösen. VisualStudio.NET macht IMHO einen Schritt in die richtige Richtung, da die Navigation im Code komfortabler geworden ist (im Vergleich zu VC++ <= ver 6) und es die Möglichkeit gibt Klammerblöcke wie in einem TreeCtrl auszublenden.
-
MaSTaH schrieb:
- Wenn es um Bibilotheken geht ist die Trennung unverzichtbar, es sei denn es gäbe eine Möglichkeit eine Schnittstellendatei generieren zu lassen.
Stimmt. Wie macht das Java?
- Wenn man (noch) keine Doku generiert hat sieht man schnell welche Funktionen in der Klasse implementiert sind.
Wär irgendwo ähnlich zu 1.
- Vielleicht bin ich es einfach gewohnt... <- scheiß Argument, ich weiß
Vielleicht bin ich es auch gewohnt. Vielleicht würde es mir fehlen, weiß ich nicht. Aber es geht mir regelmäßig extrem auf die Nüsse, dass sich Deklaration und Definition um ein const oder so unterscheiden (und dass ich im Editor doppelt soviele Buffer aufhaben muss sowieso).
-
Bashar schrieb:
MaSTaH schrieb:
- Wenn es um Bibilotheken geht ist die Trennung unverzichtbar, es sei denn es gäbe eine Möglichkeit eine Schnittstellendatei generieren zu lassen.
Stimmt. Wie macht das Java?
- Wenn man (noch) keine Doku generiert hat sieht man schnell welche Funktionen in der Klasse implementiert sind.
Wär irgendwo ähnlich zu 1.
In Java ist es üblich, eine Javadoc-Doku zu haben. Die ist ja auch ganz schnell generiert, wenn mal keine vorhanden ist. So eine Dokumentation ist deutlich komfortabler und besser nutzbar als irgendwelche Headerdateien. Auch die meisten IDEs zeigen mit Code-Completion gleich an, welche Methoden etc. eine Klasse besitzt. Wo ist also das Problem?
-
Es ging primär um die Schnittstelleninformationen in einer compilierten Library. Wenn Java keine Header hat, muss es diese ja irgendwie aus den .class-Files ziehen können. Darum gings eigentlich, nicht um Javadoc.
-
Bashar schrieb:
Es ging primär um die Schnittstelleninformationen in einer compilierten Library. Wenn Java keine Header hat, muss es diese ja irgendwie aus den .class-Files ziehen können. Darum gings eigentlich, nicht um Javadoc.
Ach so. Ja, die kannst du aus den class-Dateien ziehen. Klassennamen, Methodennamen, Konstantennamen, Methodensignaturen etc. bleiben in class-Dateien erhalten. Man kann die via Reflection herausfinden. Allerdings gehen die Parameternamen verloren.
-
allerdings benötigt die ja auch nicht, wenn man ne compilierte Lib gekauft hat.
-
Abbadon schrieb:
C++ ist Müll!
stimmt.
Abbadon schrieb:
gibts da nicht was besseres?
ja. je nach anwendungsgebiet. so würde ich lieber in lisp symbolsich differenzieren, lieber in php die webseite machen, lieber in perl den bot, lieber in vb makros für den msvc, lieber in asm den bootsektor und für 100 weitere fälle gibts auch 100 sprachen, die besser als c++ passen.
Abbadon schrieb:
Ein paar dinge fangen mich langsam wirklich an zu Nerven.
mir auch.
aber es ist breit und weit noch keine sprache in sicht, die so allgemein gut ist. in der man zur not sogar differenzieren, bots bauen und webseiten machen könnte. und noch dazu mit viel sicher und viel schnell.
-
aber es ist breit und weit noch keine sprache in sicht, die so allgemein gut ist. in der man zur not sogar differenzieren, bots bauen und webseiten machen könnte. und noch dazu mit viel sicher und viel schnell.
*a*a?
-
Bashar schrieb:
Vielleicht bin ich es auch gewohnt. Vielleicht würde es mir fehlen, weiß ich nicht. Aber es geht mir regelmäßig extrem auf die Nüsse, dass sich Deklaration und Definition um ein const oder so unterscheiden (und dass ich im Editor doppelt soviele Buffer aufhaben muss sowieso).
Na gut, es nervt schon deutlich mehr in zwei Dateien aufzusplitten seit MS in der 5er Version vom Developer-Studio den schönen H-Schalter rausgenommen hat mit dem man sofort in den Header springen konnte ;-).
-
Delphi vereint interface und implementation in einer Datei...
