Warum hat C++ so eine aufwendige Syntax?
-
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.
-
Simon2 schrieb:
- templates könnten durchschaubarer sein (friends, Basisklassen, Anforderungen an instantiierende Klassen, ...)
ja, die template-syntax ist ziemlich gruselig, aber man kann nicht C++ allein die schuld geben. oft sieht man, dass C++ user das ganze noch verschlimmern, indem sie einbuchstabige bezeichner wählen und alles in eine zeile quetschen, wie hier erst geschehen: http://www.c-plusplus.net/forum/viewtopic-var-t-is-188053-and-highlight-is-.html
wer solchen code schreibt, für den wäre vielleicht APL besser geeignetSimon2 schrieb:
- Grenze zu primitiven Typen aufheben (ableitbar, Operatoren überladen, ...)
genau. das fände ich auch gut. wenn schon op-overloading vorhanden ist, dann bitteschön für jeden operator und jeden typ.
Simon2 schrieb:
- "double dispatching"
C++ user haben schon genug probleme mit RTTI, typeid o.ä. jedesmal wenn hier einer sowas verwendet, werden ihm 'designfehler' vorgeworfen. die sprache kennt zwar OOP, aber die C++ 'userbase' will irgendwie nichts davon wissen.
'double dispatching' würden sie, nehme ich an, erst recht ablehnen.Simon2 schrieb:
- compilerübergreifendes Lib- und Klassen-Binärformat
es gibt für libs einige verbreitete binärformate wie elf/dwarf usw, allerdings enthalten libs immer maschinencode und sind daher nicht zwischen verschiedenen prozessoren austauschbar. was würde das also bringen?
Simon2 schrieb:
- Konsolenfenster schließen sich nicht mehr automatisch
huch? das ist doch sache des betriebssystems. schreib' als letzte anweisung in deine 'main' ein C++-standardkonformes 'while(true);' dann bleibt die konsole offen.
-
1967 Summer Of Love schrieb:
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.Undertaker schrieb:
...
Simon2 schrieb:
- Konsolenfenster schließen sich nicht mehr automatisch
huch? das ist doch sache des betriebssystems. schreib' als letzte anweisung in deine 'main' ein C++-standardkonformes 'while(true);' dann bleibt die konsole offen.
Anscheinend ist meine Ironie nicht als solche zu verstehen.
Gruß,
Simon2.
-
Undertaker schrieb:
Simon2 schrieb:
- Grenze zu primitiven Typen aufheben (ableitbar, Operatoren überladen, ...)
genau. das fände ich auch gut. wenn schon op-overloading vorhanden ist, dann bitteschön für jeden operator und jeden typ.
EBEN !Undertaker schrieb:
Simon2 schrieb:
- "double dispatching"
C++ user haben schon genug probleme mit RTTI, typeid o.ä. jedesmal wenn hier einer sowas verwendet, werden ihm 'designfehler' vorgeworfen. die sprache kennt zwar OOP, aber die C++ 'userbase' will irgendwie nichts davon wissen.
'double dispatching' würden sie, nehme ich an, erst recht ablehnen. ...Also gerade WEIL ich das explizite Rumhantieren mit typeids ablehne (sehr fehleranfällig und wartungsunfreundlich) würde ich ein vernünftiges double dispatching durch die Sprache befürworten !
Erst dadurch, dass es kein double dispatching gibt, muss man mit TypeIDs (seien es nun solche der eingebauten RTTI oder selbstgestrickte) was zusammenfummeln.
OOP bedeutet für mich nicht RuntimeTTI, sondern ich bin froh über alles, was mir der Compiler abnimmt.
In mir hast Du also einen typischen Vertreter der Haltung erwischt, die Du beklagst.Undertaker schrieb:
Simon2 schrieb:
- compilerübergreifendes Lib- und Klassen-Binärformat
es gibt für libs einige verbreitete binärformate wie elf/dwarf usw, allerdings enthalten libs immer maschinencode und sind daher nicht zwischen verschiedenen prozessoren austauschbar. was würde das also bringen?
Es würde bringen, dass man auf derselben Plattform mit unterschiedlichen Compilern arbeiten könnte:
- Verschiedene Entwickler im Projekt können ihren Favoriten nehmen
- ich kann jede Fremdlib einbinden
- Wenn unsere Firma auf eine neue Compilerversion wechselt, brauche ich keinen kompletten Rebuild
- "binäre Serialisierung" (im Javasinne) wäre sinnvoll möglich.
- ...
Die Grenze zu einer anderen Plattform halte ich für nicht so entscheidend, weil
- heutzutage nicht wirklich soooo viele Plattformen für eine Anwendung gebraucht werden und
- bei einer Sprache, die "durchkompiliert" (was ich gut finde) sowieso ein Binäraustausch nicht besonders sinnvoll wäre.
Klar, wenns das "dazu" gäbe (ohne wesentliche Nachteile), fände ich es gut, aber die Compilerunabhängigkeit wäre mir deutlich wichtiger.Gruß,
Simon2.
-
Artchi schrieb:
Warum werden solche Dinge nicht genannt?
Vielleicht weil die Miniproblemchen, die Du zulässt keine Sau interessieren? Vielleicht würdest Du die anderen Probleme auch erkennen, wenn Du Deine rosarote Brille abnähmest und aufhören würdest Dir hier auf die Schulter zu klopfen:
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.