C++ ist Müll!
-
Abbadon schrieb:
Aber ich will auch ab und zu richtige ausfürbare Programme erzeugen und nicht so nen komischen bytecode wie in Java.
Dann nutze Java mit einem native-Compiler, wie z.B. Excelsior JET.
-
HumeSikkins schrieb:
Abbadon schrieb:
also c++ ist ja im prinzip schon in ordnung, was mich aber zum beispiel stört sind:
[...]
-die Notwendigkeit von Funktions Prototypen
[...]Und dabei gibt's die in C++ gar nicht
Nich ?
void foo(); // Globale FUnktion die irgendwas machen soll und in bar.cpp definiert ist
Hab das irgendwann mal als Prototyp gelernt... (Würde es aber deklaration nennen).
Daher mal die Frage: Was is denn nen Funktionsprototyp und warum gibts die nich in C++ ?
-
also eine Vorwertsdeklaration einer Funktion um sie der main bekannt zu geben ist für mich ein Prototyp
oder eine deklaration einer Funktion in einem header ist ein Prototyp, die definition steht dann in der zugehörigen cppso hab ich das auf jeden fall gelernt
-
Viele Java-Programme im Desktopbereich haben auch einfach eine kleine EXE die die VM dann startet, manche IDEs können sowas auch direkt erzeugen
-
Das was du 'Prototyp' nennst, ist eine Forwaertsdeklaration oder einfach nur Deklaration.
-
Und was ist dann ein Prototyp? Na jedenfalls hat er da schon recht mit den ersten beiden Punkten. Aber der Garbage-Collector soll mal bei Java & Co bleiben.
-
DrGreenthumb schrieb:
Und was ist dann ein Prototyp?
C++ hat keine Prototypen. Diese wuerde ich eher in den OOD-Sektor packen - denn dort hat man welche
-
Hallo,
Prototypen gibt es nur in C. In C++ heißen die Dinger Deklarationen. Und was lustiges:void func();
Das ist in C++ eine Funktionsdeklaration. In C89 aber *kein* Prototyp. Denn ein C-Prototyp muss immer die Typen der Funktionsparameter enthalten.
Ein Prototyp wäre also nur:void func(void);
also eine Vorwertsdeklaration einer Funktion um sie der main bekannt zu geben ist für mich ein Prototyp
Also erstmal deklariert man eine Funktion nicht ausschließlich für main. Und zweitens: auch wenn das "für dich" ein Prototyp ist, ändert das nicht den Standard und die Tatsache, dass es in C++ keine Prototypen gibt.
Und btw: Ich habe da extra einen Smiley hinter geschrieben, da der Hinweis sehr "pedantic" und nicht so ernst gemeint war. Aber man kann natürlich auch gleich wieder krampfhaft disktutieren wollen.
-
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).