Warum hat C++ so eine aufwendige Syntax?

CStoll

mal ehrlich schrieb:

CStoll schrieb:

mal ehrlich schrieb:

Wie oft habt ihr denn schon eine "add/+" Methode geschrieben?

Ich will nicht sagen, daß ich es täglich mache, aber es kommt vor. Und wenn sich hinter einer Methode eine Addition (im weitesten Sinne) verbirgt, finde ich op+ auf jeden Fall eleganter anzuwenden als ein add().

Wieviele Methoden habt ihr schon geschrieben, bei denen es keinen passenden operator gibt?

Wohl deutlich mehr - aber das spricht doch nicht gegen die Möglichkeiten der Operator-Überladung.

Naja, ich finde es halt komisch, weil hier immer wieder Operatorüberladung als tolles Feature angepriesen wird, obwohl man es vlt. in 5% aller Fälle einsetzen kann.

Das ist ja das tolle an C++ - es gibt viele Sachen, die zwar selten angewendet werden, aber trotzdem nützlich sind (ich glaube z.B. nicht, daß schonmal jemand ALLE STL-Funktionen praktisch eingesetzt hat - aber wenn man sie braucht, ist für fast jeden Zweck etwas vorhanden).

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?

Undertaker

CStoll schrieb:

Undertaker schrieb:

CStoll schrieb:

Und für wen soll das jetzt ein Argument sein? Eine Methode add() zu schreiben ist genauso einfach oder schwierig wie die Methode 'operator+=' - sie hat nur einen anderen Namen.

man kann in C++ mehr falsch machen, z.b. pointer statt referenzen zurückgeben oder eine referenz auf eine lokale variable zurückgeben und schon geht gar nix mehr.

Was hat das bitteschön mit Operator-Überladung zu tun?

einiges. guckst du z.b: http://www.cs.caltech.edu/courses/cs11/material/cpp/donnie/cpp-ops.html
sowas würde ich mir mindestens zu gemüte führen, bevor ich überhaupt anfange, op's zu überladen.

CStoll schrieb:

...und ausserdem gehört zu einem 'operator+=' auch noch ein 'operator+', sonst ist es nicht komplett.

Wer sagt das?

mein empfinden sagt mir das. eine klasse mit += operator sollte auch +,=,- und -= implementieren, sonst wäre ich damit sehr unzufrieden.

CStoll schrieb:

PS: Ich hab's schon bei deiner letzten Inkarnation aufgegeben, dir die Vorteile von C++ erklären zu wollen - das Spiel fange ich jetzt nicht wieder von vorne an.

du musst doch nicht den c++ missionar spielen.
wir können uns einfach locker über das thema unterhalten, oder?

Artchi

Ach du schei***! Ist Undertaker Vista? Oh waier! Geht die Kinderkacke wieder von vorne los.

CStoll

Undertaker schrieb:

CStoll schrieb:

Undertaker schrieb:

CStoll schrieb:

Und für wen soll das jetzt ein Argument sein? Eine Methode add() zu schreiben ist genauso einfach oder schwierig wie die Methode 'operator+=' - sie hat nur einen anderen Namen.

man kann in C++ mehr falsch machen, z.b. pointer statt referenzen zurückgeben oder eine referenz auf eine lokale variable zurückgeben und schon geht gar nix mehr.

Was hat das bitteschön mit Operator-Überladung zu tun?

einiges. guckst du z.b: http://www.cs.caltech.edu/courses/cs11/material/cpp/donnie/cpp-ops.html
sowas würde ich mir mindestens zu gemüte führen, bevor ich überhaupt anfange, op's zu überladen.

Ja, bei der Operator-Überladung mußt du diese Probleme beachten. Aber bei der Arbeit mit "normalen" Methoden gelten diese Probleme genauso.

CStoll schrieb:

...und ausserdem gehört zu einem 'operator+=' auch noch ein 'operator+', sonst ist es nicht komplett.

Wer sagt das?

mein empfinden sagt mir das. eine klasse mit += operator sollte auch +,=,- und -= implementieren, sonst wäre ich damit sehr unzufrieden.

Aber eine Klasse, die zwar eine Methode add() (mit += Semantik), aber keine copy_add() etc anbietet, würde dich glücklicher machen?

CStoll schrieb:

PS: Ich hab's schon bei deiner letzten Inkarnation aufgegeben, dir die Vorteile von C++ erklären zu wollen - das Spiel fange ich jetzt nicht wieder von vorne an.

du musst doch nicht den c++ missionar spielen.
wir können uns einfach locker über das thema unterhalten, oder?

Ich spiele nicht den Missionar. Ich hab' nur keine Lust, mit dir über das Thema zu diskutieren.

Artchi schrieb:

Ach du schei***! Ist Undertaker Vista? Oh waier! Geht die Kinderkacke wieder von vorne los.

Und du bist, wie eigentlich immer, wieder voll mit dabei.

Jester

CStoll schrieb:

Und für wen soll das jetzt ein Argument sein? Eine Methode add() zu schreiben ist genauso einfach oder schwierig wie die Methode 'operator+=' - sie hat nur einen anderen Namen.

Ach? So einfach ist das? Wie sieht's mit Konvertierungen aus, unärem -, normales + als Member oder nicht? Implementierung von + über += etc. alles wichtige Sachen, die man erstmal erlernen muß. Sich da hinzustellen und zu sagen "ist ja alles bloß ne funktion" ist wohl reichlich kurz gedacht. Es gibt jede Menge zusätzliche Dinge zu beachten. Dass man damit tolle Sachen machen kann steht außer Frage, aber man muß es halt erstmal lernen. Und da steckt (steht hoffentlich ebenfalls außer Frage) deutlich mehr drin, als einfach nur Funktionen zu schreiben.

Undertaker schrieb:

man kann in C++ mehr falsch machen, z.b. pointer statt referenzen zurückgeben oder eine referenz auf eine lokale variable zurückgeben und schon geht gar nix mehr.

Wieso eigentlich? Kann der Compiler da keine Fehlermeldung ausgeben, wenn man eine Referenz auf eine lokale Variable zurückgibt? Oder gibts wieder einen sonderfall wo es doch irgendwie geht?

CStoll

OK, dann nochmal langsam:
Ja, du mußt einige Dinge beachten, wenn du Operator-Überladung perfekt einsetzen willst. Aber genau die selben Inkonsitenzen tauchen auch auf, wenn man das Problem nicht mit Operatoren, sondern mit "normalen" Methoden angehen will - nur sind da die Ansprüche von Nutzern seltsamerweise deutlich geringer.

(wer einen operator+ sieht, geht gleich auf die Suche nach dem zugehörigen operator+=, aber niemand hat ein Problem damit, wenn es zu einer Funktion add() kein entsprechendes add_assign() gibt)

@Holztisch: Die meisten Compiler sind in der Lage, bei sowas zu warnen. Aber bei komplexen Funktionen wird es wohl zu aufwendig, alle Möglichkeiten abzufangen.

Shade Of Mine

Tut a.add(b); jetzt eigentlich a verändern? Ich merke mir sowas irgendwie nie
Und ist es nicht irgendwie komisch dass a.add(b) != b.add(a) ist?

Wie erstelle ich ein Objekt das einfach nur den wert von a+b hat?

Foo c=a+b;

?
ne... geht ja nicht.

Foo c=new Foo(a);
a.add(b);

übersicht ftw?

Foo c=new Foo();
c.add(a).add(b);

mhm...

oder hat add() doch nicht a verändert? dann wäre es ja einfach:

Foo c=a.add(b);

aber wie addiere ich dann etwas zu a?

a=a.add(b);

mhm, das macht dann aber hier autsch:

public void foo(Foo a) {
  a=a.add(b);
}

während ein a veränderntes add() hier keine probleme bringen würde...

aber wie gesagt, der Trick mit add() ist immer: ob es das Objekt verändert oder nicht. ganz so einfach ist die sache dann doch nicht.

übrigens soll das nicht heissen dass Java oder add() schlecht ist. sondern einfach dass nicht alles so simpel ist wie es scheint. operatoren haben eigene probleme - aber das liegt nicht in der natur dass sie operatoren sind, sondern in der natur was sie tun. wie man sieht ein add() ist ein kompliziertes kleines ding und schreit nur nach fehlern. genauso wie operatoren nach fehlern schreien.

aber niemand würde versuchen

a+b;

auszuführen. ein

a.add(b);

dagegen sieht aber gut aus. auch wenn beide das selbe machen.

hat nicht jede art ihre eigenheiten?

Undertaker

CStoll schrieb:

Aber genau die selben Inkonsitenzen tauchen auch auf, wenn man das Problem nicht mit Operatoren, sondern mit "normalen" Methoden angehen will - nur sind da die Ansprüche von Nutzern seltsamerweise deutlich geringer.

was leicht verständlich ist, denn überladene operatoren sollen intuitiv anwendbar sein. wenn '+' überladen wurde gehört dazu auch, dass z.b. sowas wie 'a += b + c + d' funktioniert.

Shade Of Mine schrieb:

Tut a.add(b); jetzt eigentlich a verändern? Ich merke mir sowas irgendwie nie

ich bin für 'nicht verändern'
wenn man verändern will sollte man schreiben a = a.add(b);

CStoll

Undertaker schrieb:

Shade Of Mine schrieb:

Tut a.add(b); jetzt eigentlich a verändern? Ich merke mir sowas irgendwie nie

ich bin für 'nicht verändern'
wenn man verändern will sollte man schreiben a = a.add(b);

rein performance-technisch ist += schneller als + (letzteres braucht eine Kopie) - von daher würde ich zu einer (nicht-ändernden) add()-Methode eine (ändernde) add_assign() erwarten. Und damit sind wir wieder bei den unterschiedlichen Ansprüchen - du hast kein Problem damit, 'a=a.add(b);' zu schreiben, aber bei einem operator+ erwartest du sofort, daß es einen dazu passenden operator+= gibt, um 'a=a+b;' abkürzen zu können.

Aber das hat schon nichts mehr mit der Sprache zu tun, das ist imho lediglich eine Frage der Erwartungshaltung der Nutzer.

lolz

Also ich würde in Java folgendes bevorzugen:

Integer a,b,c;

a = add( b, c );

add_to( a, b );

da das nicht geht, würd ich zur Not auch ein

a = Math.add( b, c );

Math.add_to( a, b );

nehmen.

Wäre eindeutiger als das a.add(b).

Chris++ 0

kann man da nicht auch sowas machen?

a.gleich(a.add(b));

nur um sicherzu gehen.

Undertaker

Chris++ schrieb:

kann man da nicht auch sowas machen?
a.gleich(a.add(b));
nur um sicherzu gehen.

jetzt machst du dich aber darüber lustig

tntnet

Ich denke "Shade Of Mine" hat es sehr gut auf den Punkt gebracht. Man kann darüber diskutieren, ob "a.add(b)" nun a verändert oder nicht. Man kann aber nicht darüber diskutieren, ob "a + b" a verändert oder nicht.

Man kann natürlich mit dem operator+ auch erreichen, daß "a + b" a verändert. Dann ist es aber zweifellos ein Designfehler. Bei a.add(b) ist das Geschmackssache und daher weniger gut lesbar und begreifbar. "lolz" hat es ja im Prinzip bewiesen, wenn er sagt "Also ich würde in Java folgendes bevorzugen". Er kann nicht sagen: so ist das einzig richtige, sonder nur, daß ihm das so besser gefällt.

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.

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.