Warum hat C++ so eine aufwendige Syntax?
-
Undertaker schrieb:
CStoll schrieb:
Weil das da oben keine Definition ist
(und das ist keine Definition, um Komplikationen mit der ODR zu vermeiden)aber es hätte doch eine sein können. in 'ähnlichen sprachen' sieht das nicht so merkwürdig aus.
In diesen ähnlichen Sprachen hast du aber ein anderes Modulsystem. Man darf nunmal nicht vergessen, dass es C++ schon nen paar Jährchen länger gibt als die ganzen Sprachen mit denen man es hier vergleicht. Diese neuen Sprachen konnten bei Ihrer Entwicklung direkt aus den "Fehlern" der älteren Sprachengeneration profitieren.
Selbst C++ hätte wohl ein richtiges Modulsystem haben können, wenn ein Designziel nicht die C-Kompatibilität gewesen wäre (und ohne der wäre C++ sicherlich nicht so populär geworden).
-
Undertaker schrieb:
aber es hätte doch eine sein können. in 'ähnlichen sprachen' sieht das nicht so merkwürdig aus.
Der Grund liegt in der Natur der Sache. Du kannst in C auch nicht in einem Header "int x = 1234;" schreiben, und den Header in mehreren Sourcen inkludieren, da es dann multiple definitions vom Linker geben wird. Das ist die selbe Situation wie hier: Der Compiler muss wissen, wo "A::x" definiert wird, um das Symbol nur einmal zu erzeugen. Benutzen kann man es hingegen sooft man möchte, deshalb muss die Deklaration getrennt vorliegen.
Also hat hier die Syntax rein technisch gesehen schon eine Berechtigung.
-
kleine Bemerkung schrieb:
...
Daß C++ so komplex ist, liegt unter anderem an zwei Dingen:
1. Kompatibilität mit C (wurde schon genannt)
2. Statische Typisierung
...3. Soll eine Sprache komplexe Möglichkeiten aber nur einen möglichst begrenzten Satz an keywords und syntaktischen Zeichen (obwohl da ja außer ^°§/`´ schon fast alles dabei ist) haben, bleibt einem nicht viel Anderes übrig, als auf Konstruktionen zurückzugreifen.
Gruß,
Simon2.
-
Holztisch schrieb:
CStoll schrieb:
Wäre es nicht einfacher für die Compilerhersteller auf solche exotischen Sachen zu verzichten und statt dessen mehr Performanceoptimerung zu machen?
Was hat denn das eine mit dem anderen zu tun?
Na, ich denk mal das es einfacher ist Code zu optimieren, wenn dieser einfacher ist. Ich kann mir gut vorstellen, dass es Stellen gibt, wo man was nicht oder nur sehr aufwendig optimieren kann, weil es sein kann das etwas zusätzlicheres und komplizierteres beachtet werden muss.
Willst Du nun eine simplere Syntax (die für den menschen einfacher lesbar ist) oder eine simplere Sprache (also eine, die weniger kann) ?
Nach dem Parsing spielt die Syntax sowieso keine Rolle mehr und vorher optimiert sowieso kein Compiler. Wenn Du also eine simplere Sprache möchtest, solltest Du mal formulieren, was Dir an C++ unnötig komplex vorkommt. Geschachtelte Funktionsprototypen hast Du schon genannt ... allerdings ist das ein wenig inkonsistent, denn im globalen Namensraum willst/musst Du sie schon noch zulassen und damit hast Du letztlich nichts vereinfacht:MyType f(); // soll Funktionsprototyp sein int main() { MyType g(); // soll verboten sein ? Oder ein MyType mit DefCtor-Aufruf ? ...Ehrlich gesagt: Simplere Sprachen gibt's schon zuhauf - ich bin froh, dass C++ da mehr bietet.
Gruß,
Simon2.
-
CStoll schrieb:
PS: Jetzt wurde am Anfang nix von Java erwähnt, aber sobald es einmal gesagt wurde, gibts hier wieder Java vs C++...
Und das wundert hier noch irgendjemanden?
vielleicht hilfts wenn gerade du dich mal in solchen threads ab und zu zurückhältst...
bezüglich des a.add(b) ist eure diskussion so sinnlos wie ein kropf, macht euch erstmal klar was euer a sein soll. eine zahl? eine liste? bei letzterem wäre alles andere außer dass sich a, die liste, natürlich verändert, sinnlos
-
LordJaxom schrieb:
Der Grund liegt in der Natur der Sache. Du kannst in C auch nicht in einem Header "int x = 1234;" schreiben, und den Header in mehreren Sourcen inkludieren, da es dann multiple definitions vom Linker geben wird.
in C gibt's ja auch keine klassen und auch keine structs mit statischen membern
technisch gesehen wäre es doch kein problem. wenn der header von mehreren sources includiert würde (was ja in C++ üblich ist), dann könnte der linker doch erkennen, was 'static int A::x' ist, und dementsprechend nur ein unikat erzeugen.
btw: ich glaube es liegt eher an struppis erstem macro-compiler (CFront), der das nicht konnte und dann musste es so bleiben
-
ein gast schrieb:
CStoll schrieb:
PS: Jetzt wurde am Anfang nix von Java erwähnt, aber sobald es einmal gesagt wurde, gibts hier wieder Java vs C++...
Und das wundert hier noch irgendjemanden?
vielleicht hilfts wenn gerade du dich mal in solchen threads ab und zu zurückhältst...
Falls es dir nicht aufgefallen ist, dies ist ein C++ Forum - und wenn da jemand ankommt und "unsere" Sprache schlechtmacht, dann wird die gesamte Stamm-Mannschaft an die Decke gehen (und Java-Nutzer scheinen besonders viel Spaß daran zu empfinden, "uns" zu provozieren :D).
bezüglich des a.add(b) ist eure diskussion so sinnlos wie ein kropf, macht euch erstmal klar was euer a sein soll. eine zahl? eine liste? bei letzterem wäre alles andere außer dass sich a, die liste, natürlich verändert, sinnlos
Es geht hier nicht um a.add(b) für sich betrachtet, sondern um den Vergleich von a.add(b) vs. a+b (oder doch eher a+=b?) für eine selbstdefinierte Zahlenklasse - bei Operatoren ist die Bedeutung semantisch gegeben, bei einer Methode mußt du diese Bedeutung selber definieren. Und das ist wohl der Grund, warum Anwender mit Operatoren kritischer umgehen als mit Methoden.
Undertaker schrieb:
LordJaxom schrieb:
Der Grund liegt in der Natur der Sache. Du kannst in C auch nicht in einem Header "int x = 1234;" schreiben, und den Header in mehreren Sourcen inkludieren, da es dann multiple definitions vom Linker geben wird.
in C gibt's ja auch keine klassen und auch keine structs mit statischen membern
technisch gesehen wäre es doch kein problem. wenn der header von mehreren sources includiert würde (was ja in C++ üblich ist), dann könnte der linker doch erkennen, was 'static int A::x' ist, und dementsprechend nur ein unikat erzeugen.Ja, aber es würde einen Mehraufwand bedeuten für den Compiler, um darüber Buch zu führen - und das stört wieder die angestrebte Abwärtskompatibilität zu C (und gerade zu Zeiten, als C++ entstanden ist, wurden oft noch C-Linker verwendet, die mit solchen Daten nicht zurechtgekommen wären).
-
OK alles an C++ ist super. Zhread closed.
-
CStoll schrieb:
...dies ist ein C++ Forum...
es ist immer noch das C/C++ forum
-
Ende schrieb:
OK alles an C++ ist super. Zhread closed.
Nö, aber es ist auch nicht alles an C++ schlecht, wie es einem einige gerne verkaufen wollen.
-
Artchi schrieb:
Ende schrieb:
OK alles an C++ ist super. Zhread closed.
Nö, aber es ist auch nicht alles an C++ schlecht, wie es einem einige gerne verkaufen wollen.
Lustigerweise suchen diese Leute die Schwächen gerne da, wo C++ gar keine hat ... obwohl es genügend hat.
Ich vermute ja, dass es gar nicht darum geht, Schwäche von C++ aufzuzeigen, sondern Propaganda für die eigene Lieblingssprache zu machen - und wenn die dieselben Schwächen hat, geht's natürlich nicht anders.Gruß,
Simon2.
-
Wenn C++0x nicht die Sprache entschlackt/vereinfacht, wird sie immer unwichtiger werden. Das was ich bis jetzt gesehen habe, lässt mich allerdings stark zweifeln.
-
Prognose schrieb:
Wenn C++0x nicht die Sprache entschlackt/vereinfacht, wird sie immer unwichtiger werden. Das was ich bis jetzt gesehen habe, lässt mich allerdings stark zweifeln.
Das was ich bis jetzt gesehen habe, lässt mich allerdings stark hoffen.
Kann man sehen wie man will. Und jeder hat andere Erwartungen. Wenn C++0x in keiner Weise deinen Vorstellungen entgegen kommt, kannst du die Sprache C++ in Zukunft fallen lassen. Ich denke, da wird dir niemand auf der Welt ein Bein stellen. Außer vielleicht ein Kunde.
Ich selber sehe aber in dem, was das Komitee zur Zeit macht, eher positiv in die Zukunft. Denn es gibt sehr viele Proposals aus der Community, die vom Komitee Beachtung finden. Viele können aber aus Zeitgründen nicht in C++0x einfliessen, sind aber für den nachfolgenden Standard priorisiert.
Einfacher, im Sinne von "Features streichen", wird es aber nicht geben. Wie soll das auch gehen? Man kann nicht einfach sagen "Headers dürfen in C++0x nicht mehr als Technik vorhanden sein!". Dann kannste kein Programm mehr von heute mehr kompilieren. Aber es wird ein neues Build- und Module-System geben, das man dann in neuen Projekten einsetzen kann. Das macht die Sprache aber umfangreicher und komplexer. Also muß das Komitee einen Mittelweg finden. C++0x wird nicht eine neue Sprache sein, die man nicht wieder erkennt. Es wird C++2003 plus Bugfixes plus neuen Features sein. Nicht mehr und nicht weniger.
-
Simon2 schrieb:
Lustigerweise suchen diese Leute die Schwächen gerne da, wo C++ gar keine hat ... obwohl es genügend hat.
welche schwächen siehst du denn?
-
Artchi schrieb:
Prognose schrieb:
Wenn C++0x nicht die Sprache entschlackt/vereinfacht, wird sie immer unwichtiger werden. Das was ich bis jetzt gesehen habe, lässt mich allerdings stark zweifeln.
Das was ich bis jetzt gesehen habe, lässt mich allerdings stark hoffen.
Kann man sehen wie man will. Und jeder hat andere Erwartungen. Wenn C++0x in keiner Weise deinen Vorstellungen entgegen kommt, kannst du die Sprache C++ in Zukunft fallen lassen. Ich denke, da wird dir niemand auf der Welt ein Bein stellen. Außer vielleicht ein Kunde.
Ich selber sehe aber in dem, was das Komitee zur Zeit macht, eher positiv in die Zukunft. Denn es gibt sehr viele Proposals aus der Community, die vom Komitee Beachtung finden. Viele können aber aus Zeitgründen nicht in C++0x einfliessen, sind aber für den nachfolgenden Standard priorisiert.
Einfacher, im Sinne von "Features streichen", wird es aber nicht geben. Wie soll das auch gehen? Man kann nicht einfach sagen "Headers dürfen in C++0x nicht mehr als Technik vorhanden sein!". Dann kannste kein Programm mehr von heute mehr kompilieren. Aber es wird ein neues Build- und Module-System geben, das man dann in neuen Projekten einsetzen kann. Das macht die Sprache aber umfangreicher und komplexer. Also muß das Komitee einen Mittelweg finden. C++0x wird nicht eine neue Sprache sein, die man nicht wieder erkennt. Es wird C++2003 plus Bugfixes plus neuen Features sein. Nicht mehr und nicht weniger.
Dann wird C++ in der Zukunft immer unwichtiger sein und abgesehen von paar Branchen wie Spieleprogrammierung verlieren gegen moderne Sprachen. Im Jahr 2010 noch mit Headern und include guards rumfrickeln is einfach nur noch lächerlich.
-
Undertaker schrieb:
Simon2 schrieb:
Lustigerweise suchen diese Leute die Schwächen gerne da, wo C++ gar keine hat ... obwohl es genügend hat.
welche schwächen siehst du denn?
Och, nur mal so locker reingeworfen, was man IMO verbessern könnte (unpriorisiert einfach mal, was mir gerade so einfällt):
- templates könnten durchschaubarer sein (friends, Basisklassen, Anforderungen an instantiierende Klassen, ...)
- Grenze zu primitiven Typen aufheben (ableitbar, Operatoren überladen, ...)
- "keine throw-Spez." == "throw()" => throw-Spez. zur Compilezeit auswertbar => throw-Spez. benutzbar (Bin mir aber nicht ganz sicher mit diesem Punkt ... vielleicht sind rigide throw-Spez. auch zu eng)
- "double dispatching"
- compilerübergreifendes Lib- und Klassen-Binärformat
- Overloading in abgeleiteten Klassen ohne explizites using
- cin.ignore()
- vernünftige Datums- und Zeitfunktionalitäten
- "virtual Vererbung" an anderer Stelle kennzeichnen (nicht an der Basis sondern an der Blattklasse)
- Konsolenfenster schließen sich nicht mehr automatisch
- ...Stattdessen kommen immer nur so Sachen wie "Pointer sind gefährlich" oder "Operatorüberladung braucht man nicht"...
:p Gruß,
Simon2.
-
Ich finde die Header und cpp Trennung nicht schlecht. Besser als wenn man alles in einer Datei stehen hat und doppelt so viel scrollen muss nur um mal irgendwo eine Funktion zu finden. Aber man kann alles Schlechtreden wenn man will. Letztenendes wird die Industrie entscheiden welche Sprache gerade "in" ist.
Ich finde es aber echt lächerlich das es hier auch schon wie in den "Gamer Haxor" Foren abgeht. Wenn man eine Sprache bevorzugt, dann wird man gleich als "Fanboy" abgestempelt. Diskusionen sind nicht mehr möglich. Bla bla bla.
-
Prognose schrieb:
...Im Jahr 2010 noch mit Headern und include guards rumfrickeln is einfach nur noch lächerlich.
Hä ?
Was ist DAS denn für eine Aussage ?
Header sind eine erstklassige Methode, ein Interface zu beschreiben und der Entkopplung und dass es eine ODR gibt, ist auch kein Nachteil.....
Gruß,
Simon2.
-
Simon2 schrieb:
- Konsolenfenster schließen sich nicht mehr automatisch
lol
Wenn ich ne Konsole öffne, dann bleibt die auch offen. Mach doch mal Windowtaste + R -> cmd ... die bleibt offen.
-
Simon2 schrieb:
Stattdessen kommen immer nur so Sachen wie "Pointer sind gefährlich" oder "Operatorüberladung braucht man nicht"...
:p Ich habe da auch noch so ein paar Schnitzer, über die ich gestolpert bin. Die hier aber nie genannt wurden.
Warum werden solche Dinge nicht genannt? Weil die Leute nie intensiv mit C++ gearbeitet haben aber trotzdem ne große Fresse haben und die uralten Argumente, die sie mal gelesen/gehört haben, bringen. Würden sie wirklich mit C++ gearbeitet haben, würden sie ganz andere Themen auf den Tisch bringen.