Ansi C Operator überladen?

[mikey]

fußgänger schrieb:

naja, so ganz unrecht hat pale dog nicht. ich hab auch schon oft c++ code gesehen, wo mich die operatorüberladung eher verwirrt hat als mir zu helfen. vor allem, da man in c++ 4583483 sachen bei der operatorüberladung beachten muss, find ichs ganz gut, wenn die sprache sowas garnicht erst anbietet - und wenn, dann in vereinfachter syntax wie zb in c#

Wir reden von der Anwendung der Operatoren, nicht von deren Definierung. Deine Kritisierung finde ich (sorry) etwas lächerlich. Es ist schlicht keine Rechtfertigung, zu behaupten, "Operatorüberladung gestaltet sich schwierig", oder "Man muss 4583483 Sachen dabei beachten". Nunja, wo muss man das nicht? Zudem ist das wohl die Sicht eines Anfängers. Operatorüberladung ist in keinster Weise so komplex, dass man es schwer verstehen, oder gar abschaffen sollte.

[lolz]

Reyx schrieb:

set() und get() sind wesentlich abstraker. Man weiß, dass etwas gesetzt oder abgerufen wird, mehr nicht.

Du nimmst an dass das geschieht, aber sicher sein kannst du dir nicht (das ist ja die Argumentation gegen die Operatorüberladung.

Dies sollte zutreffen, sofern der Programmierer nicht bewusst Mist baut. operator+ und operator- sind interpretationsabhängig, was ich aber nicht als Nachteil sehen würde.

Eigentlich ist es nicht interpretationsabhängig, da ein Misbrauch eines operator+ für einen anderen Zweck nicht die Regel ist (wenn man euch hört meint man das aber gerade zu), sondern überhaupt nicht vorkommen soll.

Bei add() oder operator+ nehme ich an, dass etwas addiert wird. Alles andere wäre (bewusste) Irreführung von dem Programmierer der Klasse.

[quote]
naja, so ganz unrecht hat pale dog nicht. ich hab auch schon oft c++ code gesehen, wo mich die operatorüberladung eher verwirrt hat als mir zu helfen. vor allem, da man in c++ 4583483 sachen bei der operatorüberladung beachten muss, find ichs ganz gut, wenn die sprache sowas garnicht erst anbietet - und wenn, dann in vereinfachter syntax wie zb in c#[/uote]
Was muss man denn beachten?

Ein großes Manko an der Operatorüberladung ist die Freiheit, da ein a = a + b; nicht das gleiche sein muss wie a += b; da wäre es wünschenswert wenn die Operatorüberladung nicht so direkt funktionieren würde, sondern man Konzepte implementiert die dann z.B. auf a = a + b; oder a += b; abgebildet werden.
Nicht weil ich Misbrauch fürchte, sondern die Gefahr gesenkt wird, dass man versehentlich die beiden verschieden implementiert (oder beim Ändern des einen den anderen vergisst).

P.S. ja ich weiß, dass man als Lösung den einen operator mit Hilfe des anderen implementiert.

[Gast]

Was mich jetzt als nicht-OOPler (zumindest nicht in dem Sinne wie es hier wohl meist verstanden wird) etwas wundert: Normalerweise findet man als OOPler ja alles geil was "Information hiding" und Abstraktion etc. angeht. Aber bei Operatorüberladung ist eben dies nicht mehr gewünscht? Wie kommt es dazu?

[mikey]

Warum sollte beim OP-Überladen Abstraktion nicht mehr gewünscht sein? Man definiert den Operator gezielt als öffentliche Methode, mit der man dafür vorgesehene Datentypen bearbeiten kann (addieren, ausgeben etc.) Natürlich kann man auch mit dem Indexoperator [] auf private Member zugreifen, aber das ist dann auch gezielt im Sinne der OOP (und des Programmierers!)

[rüdiger]

pale dog schrieb:

rüdiger schrieb:

Und wieder: Wo ist der Unterschied zwischen einer Methode add und einem operator+ ?

der operator+ erscheint, wenn er benutzt wird, nicht als 'operator+' sondern als einfaches '+' d.h. man sieht ihm in seiner unscheinbarkeit nicht an, dass sich dahinter ein ganzer wust von code verbirgt. bei einer funktion 'add()' dagegen (auch wenn ihr name irreführend sein mag), sieht jeder blinde mit krückstock den funktionsaufruf und kann konsequenzen berücksichtigen, die dadurch entstehen.

Ich weiß ja auch nicht was der Compiler aus einem builtin operator+ macht. Außerdem sehe ich nicht den Grund, warum ich die Details des Operator+ wissen muss. Klar da kann viel Code hinter stecken. Aber wenn ich eine Addition brauche, brauche ich eben eine Addition.

Ich kann die add-Methode auch a-Methode nennen und schon ist die ebenfalls sehr unscheinbar...

lolz schrieb:

pale dog schrieb:

genau das, was ich die ganze zeit anprangere: die bedeutung von + und - wird auf's übelste verfälscht!

Bei operator- und operator+ wird also aufs übelste verfälscht. Aber die Methoden set und get nicht?

doch, die auch, das habe ich nicht bestritten.
falsche, elementare operatoren, die nicht funktionieren, empfinde ich aber als wesentlich schlimmer als verbugte funktionen...

Warum sind die Operatoren elementar? Ich kann ja nicht die Ops der Builtin-Typen überladen.

[Simon2]

pale dog schrieb:

...
klar, aber ich kann es erkennen, wenn ich den code sehe:...
hättest du aber einen der operatoren, das = oder das << überladen, dann würde man schon weniger aussagen über den code machen können:...

Sorry, aber warum ? operatoren SIND einfach nur Funktionen (die allerdings ein wenig einfacher aufgerufen werden können).
Die Möglichkeiten/Einschränkungen, die Du bei den einen hast, hast Du auch bei den anderen -
- wenn ein operator+() nicht das tut, was es soll, kann Dir das mit einem get() genauso passieren.
- Wenn Dich das beim get() nicht stört, weil Du den Quellcode siehst, braucht es Dich beim operator+() ebensowenig zu stören, weil Du ihn Dir genauso ansehen kannst.

pale dog schrieb:

...

lolz schrieb:

...
Quark.

class A {
   int i;
public:
   int operator-() { i = 7; return 5; }
   void operator+(int a) { outFile << a; }
};

Und was hat sich jetzt geändert?

genau das, was ich die ganze zeit anprangere: die bedeutung von + und - wird auf's übelste verfälscht!...

Exkt wie beim get/set-Beispiel.

Also: Mit dem Argument "Man kann anderes tun als der Name suggeriert" müsste man gleichzeitig freie Benennung von Funktionen untersagen.

pale dog schrieb:

MFK schrieb:

pale dog schrieb:

in einem quelltext sieht man aber 'a = b + c;' und das sieht aus wie die addition zweier primitiver datentypen.

Das mag für dich so aussehen. Ich sehe da einen operator+ und einen operator=, und weiß, was das bedeuten kann.

und woher?...

Weil's im Quellcode so steht !

Gruß,

Simon2.

[Simon2]

Reyx schrieb:

set() und get() sind wesentlich abstraker. Man weiß, dass etwas gesetzt oder abgerufen wird, mehr nicht. Dies sollte zutreffen, sofern der Programmierer nicht bewusst Mist baut. operator+ und operator- sind interpretationsabhängig, was ich aber nicht als Nachteil sehen würde.

Hi,

sorry, aber da schließt Du jetzt ziemlich stark von Dir auf andere ("...man...").
Mit ein wenig Erfahrung weiß man, was getter/setter UND operator-/operator+ semantisch bedeuten. Mangelt einem diese Erfahrung, muß man beim get/set genauso nachsehen (oder kann ebenso "intuitiv danebenliegen").

Gruß,

Simon2.

[fußgänger]

mikey schrieb:

fußgänger schrieb:

naja, so ganz unrecht hat pale dog nicht. ich hab auch schon oft c++ code gesehen, wo mich die operatorüberladung eher verwirrt hat als mir zu helfen. vor allem, da man in c++ 4583483 sachen bei der operatorüberladung beachten muss, find ichs ganz gut, wenn die sprache sowas garnicht erst anbietet - und wenn, dann in vereinfachter syntax wie zb in c#

Wir reden von der Anwendung der Operatoren, nicht von deren Definierung. Deine Kritisierung finde ich (sorry) etwas lächerlich. Es ist schlicht keine Rechtfertigung, zu behaupten, "Operatorüberladung gestaltet sich schwierig", oder "Man muss 4583483 Sachen dabei beachten". Nunja, wo muss man das nicht? Zudem ist das wohl die Sicht eines Anfängers. Operatorüberladung ist in keinster Weise so komplex, dass man es schwer verstehen, oder gar abschaffen sollte.

Es geht um Operatoren. Also auch um die Definition. Und natürlich spielt es ne Rolle, wenn die Implementierung eklig is und voller Fallstricke. Wie bist du denn bitte drauf? Du fragst wo man nich 54858949584 Dinge beachten muss? Vllt bei den neueren, eleganteren, ballastfreieren Sprachen wie Java und C#? Offenbar bist du nen C++ Fanboy und nimmst es als Maß aller Dinge.

[Apollon]

pale dog schrieb:

[...] aber echt übel: denk doch mal an C++ iostreams, wie da die shift-operatorn missbraucht werden.
*das* ist richtig mies!

Aber auch nur, weil Du die Analogie nicht raffst.

[rüdiger]

fußgänger schrieb:

Es geht um Operatoren. Also auch um die Definition. Und natürlich spielt es ne Rolle, wenn die Implementierung eklig is und voller Fallstricke. Wie bist du denn bitte drauf? Du fragst wo man nich 54858949584 Dinge beachten muss?

Was muss man bitte bei Operatoren beachten?

[pale dog]

rüdiger schrieb:

pale dog schrieb:

rüdiger schrieb:

Und wieder: Wo ist der Unterschied zwischen einer Methode add und einem operator+ ?

der operator+ erscheint, wenn er benutzt wird, nicht als 'operator+' sondern als einfaches '+' d.h. man sieht ihm in seiner unscheinbarkeit nicht an, dass sich dahinter ein ganzer wust von code verbirgt. bei einer funktion 'add()' dagegen (auch wenn ihr name irreführend sein mag), sieht jeder blinde mit krückstock den funktionsaufruf und kann konsequenzen berücksichtigen, die dadurch entstehen.

Ich weiß ja auch nicht was der Compiler aus einem builtin operator+ macht.

warum nicht? addition/multiplikation etc. hat fast jede CPU und wenn man sich mal den asm-output des compilers angeschaut hat, weiss man ungefähr, was der daraus macht. z.b. weiss man dann, dass zum addieren von 'ints' kein funktionsaufruf nötig ist (an beliebiger stelle). ein 16-bitter könnte für die addition zweier longs z.b. eine funktion aufrufen, für die addition zweier fliesskommawerte sowieso. das weiss man einfach, wenn man sein system kennt und manchmal ist dieses wissen von bedeutung.

rüdiger schrieb:

Ich kann die add-Methode auch a-Methode nennen und schon ist die ebenfalls sehr unscheinbar...

du siehst aber trotzdem, dass es eine funktion ist. egal wie sie heisst. wieviele funktionsaufrufe stecken wohl in:

sometype_t s;
othertype_t a;
for (s=0; s<100; s++)
  a[s] = s*s;

in C, mit kenntnis meiner target-CPU und meines verwendeten compilers weiss ich auf den ersten blick wieviele es sind. weisst du es auch in einer sprache, in der man die operatoren alle umdefinieren kann? wohl nur, wenn man sich vorher tonnenweise anderen code verinnerlicht hat.

Simon2 schrieb:

pale dog schrieb:

...
klar, aber ich kann es erkennen, wenn ich den code sehe:...
hättest du aber einen der operatoren, das = oder das << überladen, dann würde man schon weniger aussagen über den code machen können:...

Sorry, aber warum ? operatoren SIND einfach nur Funktionen (die allerdings ein wenig einfacher aufgerufen werden können).

nicht immer. wir sind ja mittlerweile bei C++ gelandet, da gibt es beides, die selbstgemachten (operator() funktionen) und die eingebauten operatoren.

Simon2 schrieb:

pale dog schrieb:

MFK schrieb:

pale dog schrieb:

in einem quelltext sieht man aber 'a = b + c;' und das sieht aus wie die addition zweier primitiver datentypen.

Das mag für dich so aussehen. Ich sehe da einen operator+ und einen operator=, und weiß, was das bedeuten kann.

und woher?...

Weil's im Quellcode so steht !

ja, aber in welchem? in der zeile 'a = b + c;' jedenfalls nicht.

Apollon schrieb:

pale dog schrieb:

[...] aber echt übel: denk doch mal an C++ iostreams, wie da die shift-operatorn missbraucht werden.
*das* ist richtig mies!

Aber auch nur, weil Du die Analogie nicht raffst.

was hat ein- und ausgabe mit bitgeschubse zu tun?
genau so gut hätten sie operator+() für das hinzufügen in einen stream und operator-() für das auslesen von streams definieren können.
eine analogie (+ bedeutet etwas dazutun und - bedeutet etwas wegnehmen) ist da, aber käme dir das nicht seltsam vor: 'cout + "hello, world";'

[MFK]

pale dog schrieb:

man sieht ihm in seiner unscheinbarkeit nicht an, dass sich dahinter ein ganzer wust von code verbirgt.

Nicht "man". Du.

bei einer funktion 'add()' dagegen (auch wenn ihr name irreführend sein mag), sieht jeder blinde mit krückstock den funktionsaufruf und kann konsequenzen berücksichtigen, die dadurch entstehen.

Und jemand, der (im Gegensatz zu dir) den Umgang mit C++ gewöhnt ist), sieht das auch bei + und =.

wenn man sich mal den asm-output des compilers angeschaut hat, weiss man ungefähr, was der daraus macht. z.b. weiss man dann, dass zum addieren von 'ints' kein funktionsaufruf nötig ist (an beliebiger stelle).

Nicht "man". Du.

ein 16-bitter könnte für die addition zweier longs z.b. eine funktion aufrufen, für die addition zweier fliesskommawerte sowieso. das weiss man einfach,

Nicht "man". Du.

wenn man sein system kennt und manchmal ist dieses wissen von bedeutung.

Und wenn nicht? Muss jeder C und Assembler und seine Prozessorarchitektur kennen wie du, damit er C++ wie du schlecht finden darf, nur weil du deine Scheuklappen nicht mehr los wirst?

in C, mit kenntnis meiner target-CPU und meines verwendeten compilers weiss ich auf den ersten blick wieviele es sind.

Wenigstens hast du hier nicht "man" gesagt.

hättest du aber einen der operatoren, das = oder das << überladen, dann würde man schon weniger aussagen über den code machen können:...

Nicht "man". Du.

was hat ein- und ausgabe mit bitgeschubse zu tun?

Nichts. Macht aber auch nichts. Wann braucht man schon mal Bitshift-Operatoren?

Du hast anscheinend so lange in deiner C-Welt gelebt, dass du Dinge wie Operatorüberladung nur ablehnen kannst, weil sie nicht in dein Weltbild passen. Es ist mir auch egal, was du davon hältst. Mich stört nur, dass du deine Ansichten, vor allem was "man" so aus Quellcode herausliest, auf Andere überträgst. Kannst du dich damit abfinden, dass Andere möglicherweise etwas niedrigere Tellerränder haben als du?

[Simon2]

[quote="pale dog"]

Simon2 schrieb:

...
nicht immer. wir sind ja mittlerweile bei C++ gelandet, da gibt es beides, die selbstgemachten (operator() funktionen) und die eingebauten operatoren....

Nein ! Wieso sollten sich die einen von den anderen unterscheiden ?
Doch bestenfalls, dass man für

int f(int i) { return i+1; }

Keine separate Deklaration für f braucht, sondern direkt initialisieren kann. Ist halt eine globale Varable vom Typ struct { int operator()(int); }

pale dog schrieb:

Simon2 schrieb:

pale dog schrieb:

MFK schrieb:

pale dog schrieb:

in einem quelltext sieht man aber 'a = b + c;' und das sieht aus wie die addition zweier primitiver datentypen.

Das mag für dich so aussehen. Ich sehe da einen operator+ und einen operator=, und weiß, was das bedeuten kann.

und woher?...

Weil's im Quellcode so steht !

ja, aber in welchem? in der zeile 'a = b + c;' jedenfalls nicht.

Doch: 'a = b + c;'

Ansonsten schließe ich mich MFK an: Nicht "man", sondern "Du".

Gruß,

Simon2.

[CStoll]

pale dog schrieb:

Ich weiß ja auch nicht was der Compiler aus einem builtin operator+ macht.

warum nicht? addition/multiplikation etc. hat fast jede CPU und wenn man sich mal den asm-output des compilers angeschaut hat, weiss man ungefähr, was der daraus macht. z.b. weiss man dann, dass zum addieren von 'ints' kein funktionsaufruf nötig ist (an beliebiger stelle). ein 16-bitter könnte für die addition zweier longs z.b. eine funktion aufrufen, für die addition zweier fliesskommawerte sowieso. das weiss man einfach, wenn man sein system kennt und manchmal ist dieses wissen von bedeutung.

Im Endeffekt ist trotzdem alles eine Funktion, auch wenn die teilweise inline aufgelöst werden könnten (aber das kann der Compiler je nach Typ auch mit deinen eigenen Operatoren machen)

rüdiger schrieb:

Ich kann die add-Methode auch a-Methode nennen und schon ist die ebenfalls sehr unscheinbar...

du siehst aber trotzdem, dass es eine funktion ist. egal wie sie heisst. wieviele funktionsaufrufe stecken wohl in:

sometype_t s;
othertype_t a;
for (s=0; s<100; s++)
  a[s] = s*s;

in C, mit kenntnis meiner target-CPU und meines verwendeten compilers weiss ich auf den ersten blick wieviele es sind. weisst du es auch in einer sprache, in der man die operatoren alle umdefinieren kann? wohl nur, wenn man sich vorher tonnenweise anderen code verinnerlicht hat.

Soll ich?

1. Default-Ctor von sometype_t
2. Default-Ctor von othertype_t
3. op=
4. op<
5. op++
6. op[]
7. op*
8. op=

Das macht 8 Funktionsaufrufe (und bis zu 7 Typ-Umwandlungen, um die Parameter zu korrigieren)

Simon2 schrieb:

pale dog schrieb:

...
klar, aber ich kann es erkennen, wenn ich den code sehe:...
hättest du aber einen der operatoren, das = oder das << überladen, dann würde man schon weniger aussagen über den code machen können:...

Sorry, aber warum ? operatoren SIND einfach nur Funktionen (die allerdings ein wenig einfacher aufgerufen werden können).

nicht immer. wir sind ja mittlerweile bei C++ gelandet, da gibt es beides, die selbstgemachten (operator() funktionen) und die eingebauten operatoren.

Die eingebauten Operatoren sind aus Sicht des Programmierers auch nur Funktionen (die der Compiler eventuell besonders gut optimieren kann).

Simon2 schrieb:

pale dog schrieb:

MFK schrieb:

pale dog schrieb:

in einem quelltext sieht man aber 'a = b + c;' und das sieht aus wie die addition zweier primitiver datentypen.

Das mag für dich so aussehen. Ich sehe da einen operator+ und einen operator=, und weiß, was das bedeuten kann.

und woher?...

Weil's im Quellcode so steht !

ja, aber in welchem? in der zeile 'a = b + c;' jedenfalls nicht.

Wo schaust du nach, wenn du z.B. "a.add(b);" liest und wissen willst, was es bedeuten soll? Richtig - in der Definition der Methode add(). Genauso sieht sich ein halbwegs erfahrener C++ Programmierer zunächst an, was hinter a, b und c steht, und findet in der entsprechenden Klassendefinition die richtigen Operatoren.

Apollon schrieb:

pale dog schrieb:

[...] aber echt übel: denk doch mal an C++ iostreams, wie da die shift-operatorn missbraucht werden.
*das* ist richtig mies!

Aber auch nur, weil Du die Analogie nicht raffst.

was hat ein- und ausgabe mit bitgeschubse zu tun?
genau so gut hätten sie operator+() für das hinzufügen in einen stream und operator-() für das auslesen von streams definieren können.
eine analogie (+ bedeutet etwas dazutun und - bedeutet etwas wegnehmen) ist da, aber käme dir das nicht seltsam vor: 'cout + "hello, world";'

Bei den Streams schiebt man nicht mehr einzelne Bits, sondern ganze Objekte - und da kannst du die Operatoren auch als Pfeile ansehen, die die Richtung vorgeben, in die die Daten fließen.

[pale dog]

MFK schrieb:

Du hast anscheinend so lange in deiner C-Welt gelebt, dass du Dinge wie Operatorüberladung nur ablehnen kannst, weil sie nicht in dein Weltbild passen.

total ablehnen würde ich nicht sagen, es ist nur sehr schwierig, op-overloading sinnvoll anzuwenden d.h. meistens macht es eben keinen sinn und in der realität entsteht oft fehlerträchtiger und schwer verständlicher code dadurch. um mal wieder C++ als negativbeispiel zu nehmen: viele C++-fans basteln sich stringklassen, oder benutzen vorhandene, bei denen der operator+() zum zusammenfügen von strings überladen ist. das mag im ersten augenblick intuitiv wirken, hat aber den haken, dass a+b nicht b+a ist. für mich wäre das z.b. ein grund, operator+() als stringverketter erst gar nicht in betracht zu ziehen.
(ich hoffe hier sind jetzt nicht zu viele 'man's drin)
übrigens, hier: http://richardhaleshawgroup.com/RHSGroup/Community/blogs/richard_hale_shaws_blog/archive/2005/10/06/176.aspx
wenn man diese liste beachtet, würde man op-overloading wahrscheinlich nie einsetzen...

CStoll schrieb:

was hat ein- und ausgabe mit bitgeschubse zu tun?
genau so gut hätten sie operator+() für das hinzufügen in einen stream und operator-() für das auslesen von streams definieren können.
eine analogie (+ bedeutet etwas dazutun und - bedeutet etwas wegnehmen) ist da, aber käme dir das nicht seltsam vor: 'cout + "hello, world";'

Bei den Streams schiebt man nicht mehr einzelne Bits, sondern ganze Objekte - und da kannst du die Operatoren auch als Pfeile ansehen, die die Richtung vorgeben, in die die Daten fließen.

okay, aber warum haben sie nicht operator=() genommen (dem stream etwas zuweisen)?
würde doch auch gehen, oder nicht?

[CStoll]

Ja, in manchen Fällen ist das eine Design-Entscheidung (und + für String-Verkettung ist möglicherweise grenzwertig), aber das ist kein generelles Problem der Sprache, sondern höchstens des Verständnisses. Jedes Sprachmittel hat sein Probleme und Fallstricke, aber deswegen macht es noch lange keinen Sinn, es zu verbieten.

[pale dog]

CStoll schrieb:

Jedes Sprachmittel hat sein Probleme und Fallstricke, aber deswegen macht es noch lange keinen Sinn, es zu verbieten.

da hast du recht, aber wenn jemand eine programmiersprache entwickelt, sollte er sich genau überlegen, was man einbaut, wie es funktioniert, welche vor- und nachteile dadurch entstehen, ob missbräuchliche anwendung forciert wird usw.usw...
sozusagen: 'usability' einer programmiersprache, auch in bezug auf les- und wartbarkeit von codes. das ist natürlich nicht einfach...

[CStoll]

Dann mach's besser Ich bin vielleicht nicht ganz so paranoid wie du, aber in meinen Augen sieht "a=b+c;" einfach besser und übersichtlicher aus als "a.assign(sum(b,c));" (außerdem ist die intuitive Bedeutung von Operatoren klarer als bei Funktionsnamen). Und Müll fabrizieren kann man mit beiden Konstruktionen genauso viel.

Also warum sollte man ein existierendes Sprachmittel (Operatoren) nur für eine kleine Gruppe an Datentypen erlauben, während alle anderen mit umständlichen Methodenverschachtelungen hantieren müssen?

[Marc++us]

@pale dog: ich verstehe Dein Problem nicht ganz. Ich gebe zu, daß man mit der Operatorüberladung furchtbare Dinge tun kann, z.B. einen Funktionsaufruf in ein + packen, das kann kein Mensch mehr lesen. [Es gab ein furchtbares Beispiel dafür in Borlands Fensterbibliothek TurboVision für DOS, so um 1994, da haben sie MenuItems mit + an die Menüs angehängt. In keiner Weise intuitiv.]

Aber was kann man daraus folgern? Nichts.

Denn es ist auch erlaubt, alle Klassennamen und Methodennamen mit nur einem Buchstaben zu benennen, oder man nennt alles a1, a2, a3, a4 - auch das wäre unlesbarer Code, und ist trotzdem legales C++ (bzw ist das Beispiel auf jede Sprache übertragbar).

Und ab dem Punkt sagt man eben "jeder Programmierer ist seines eigenen Glückes (und Unglückes) Schmied"... Sprachmittel unvernünftig einzusetzen lässt sich durch die Sprache selbst nicht wirklich verhindern. Schaffst Du das Mittel ab, finden findige Programmierer andere Wege, ihre Programme obfuscated zu machen.

[Gast++]

Hab den Thread mal quer gelesen und erspar es mir infolge des mittlerweile doch ergheblichen Umfanges jeweils zu zitieren. Es mag sein dass ich einiges wiederhole, das bitte ich die jeweiligen Urheber mir zu verzeihen.

1. "Missbrauch von '>>' und '<<' in der STL"
   Genau diese Konstrukte waren für mich vor zehn Jahren der Grund es mal mit C++ zu versuchen.
   Die sind intutiv zu verstehen und verschlanken den Code ungemein

Ein

printf("Hausnummer:%i\t Name:%s\n",42,"RMS")

isr sicherlich schwerer lesbar als das iostream-Pendant.

2. Konfusion
   Als ich dann verstand dass man auch '[]' überladen kann war mir klar dass das die geeignte Sprache für mich wäre. Was soll

myVec[42];

denn wohl anderes sein das 43. Element von etwas Array-ähnlichem - dass man bei 0 anfängt weiss auch der "C"-ler.

3. Effizienz
   "String + String ist ein Funktionsaufruf, a + b nicht" - das vergleicht Äpfel mit Birnen. Wenn man eine

class Int {/***/};

mit allen Operatoren denn zu brauchen meint könnte mandarüber hinaus die Operatoren auch noch

inline

deklarieren.

Und ob aus

int c = a + b;

nun wirklich einfach

push eax
mov  eax,a
add  eax,b
mov  c,eax
pop  eax

wird, mag ich auch noch bezweifeln.

Ich sehe überhaupt keine prinzipiellen Bedenken gegen Überladungen, ganz im Gegenteil: das Klassenkonzept von C++ ermöglicht es mit Überladungen das Verhalten einer Instanz in der "Aussenwelt", hier also die Sprachumgebung, genauestens zu definieren.
Dass man nicht mit

Int::operator+

substrahieren sollte verstehet sich wohl von selbst.

Ferner wird gegen C++ immer wieder mangelnde "Mächtigkeit" ( im Sinne von CPU-Befehlen pro Codezeile) ins Feld geführt; gerade aus der Java-Gemeinde.
Mit Operatoren kann ich ähnliche Mächtigkeit erreichen wie sie sonst nur Skriptsprachen anbieten; da sind die Operatoren halt nicht überladen sondern per se mehrdeutig.

Für mich ist es ein Qualitätsmerkmal einer allgemeinen Klasse wenn mehrere überladene Operatoren für sie definiert sind - z.B. gearde

ostream& operator<<(...)

weil sie dann viel schlanker zu verwenden ist.

Grüsse

Gast++