Warum hat C++ so eine aufwendige Syntax?

Xin

Undertaker schrieb:

Xin schrieb:

...aber grundsätzlich muss man C++ als eine der besten Sprachen auf dem Markt akzeptieren.

weil sie weit verbreitet ist bzw. oft genutzt wird, oder wieso meinst du das?

Wenn Du Dir Stellenangebote ansiehst, so wird Java und C# werden inzwischen deutlich mehr genutzt als C++.

Ich halte C++ für die leistungsfähigere Sprache, doch gefragt sind inzwischen Sprachen, die bei weniger Erfahrung und Qualifikation schneller Resultate liefern.

Undertaker

das mit den selbstgemachten operatoren ist noch nicht mal das schlimmste. sowas z.b:

class A
{
    static int x;
};
int A::x = 1234;

ist extrem doofe syntax. warum kann man die initialisierung nicht bei der definition mit angeben?

minhen

tntnet schrieb:

Operatorüberladung dient dazu, den Code lesbarer zu machen. Die Kritiker dieses Features zeigen immer wieder Beispiele, wo das misbraucht wird, um Code unlesbar zu machen. Richtig angewandt verbessert es aber den Code.

Natürlich hätte C++ eine einfachere Syntax, wenn es Operatorüberladung nicht gäbe. Auch Java hätte eine einfachere Syntax, wenn es while-Schleifen nicht gäbe. Ich bevorzuge aber eine Sprache, die mir die Ausdrucksmittel zur Verfügung stellt, um meinen Code möglichst intuitiv lesbar macht.

“The very fact that it’s possible to write messy programs in Perl is also what makes it possible to write programs that are cleaner in Perl than they could ever be in a language that attempts to enforce cleanliness” (Larry Wall: Linux World, 1999)

... das gilt so sicherlich auch für C++.

CStoll

Undertaker schrieb:

das mit den selbstgemachten operatoren ist noch nicht mal das schlimmste. sowas z.b:
class A
{
    static int x;
};
int A::x = 1234;
ist extrem doofe syntax. warum kann man die initialisierung nicht bei der definition mit angeben?

Weil das da oben keine Definition ist (und das ist keine Definition, um Komplikationen mit der ODR zu vermeiden)

Undertaker

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.

lolz

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).

LordJaxom

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.

Simon2

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.

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

Undertaker

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

CStoll

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.

Undertaker

CStoll schrieb:

...dies ist ein C++ Forum...

es ist immer noch das C/C++ forum

Artchi

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.

Simon2

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.

Artchi

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.

Undertaker

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.