Ansi C Operator überladen?



  • rüdiger schrieb:

    Und warum interessiert es mich ob ich gerade zwei primitive oder zwei nicht primitive Objekte addiere? Mich interessiert doch nur, dass die Addition statt findet.

    Genau das war ja das Argument: Was man addiert ist nicht fraglich, fraglich ist nur, ob man addiert!

    Abgesehen davon halte ich die Debatte für sinnlos. Wieso gehen bei "Das ist gut/Das ist schlecht?"-Argumentationen die Contra immer davon aus, der Programmierer wäre zu blöd, überhaupt Quellcode zu lesen, und Pro immer davon aus, der Programmierer könnte jeden Quellcode lesen?



  • ich gehe davon aus das es ein mächtiges werkzeug ist

    wie jedes mächtige werkzeug hat es sowohl vorteile als auch nachteile

    diese entwickeln sich je nach nutzung und sorgfalt
    daher ist es überaus sinnvoll das ganze mit vorsicht zu geniesen,
    aber nicht generell zu verteufeln nur weil es den programmierertyp "codemonkey" überfordert



  • Reyx schrieb:

    rüdiger schrieb:

    Und warum interessiert es mich ob ich gerade zwei primitive oder zwei nicht primitive Objekte addiere? Mich interessiert doch nur, dass die Addition statt findet.

    Genau das war ja das Argument: Was man addiert ist nicht fraglich, fraglich ist nur, ob man addiert!

    Das gleiche kann man aber auch über einer add() Methode sagen. Weshalb dieser Aspekt doch gar keiner Argumentation bedarf. Denn hier unterscheiden sich eine Methode oder ein überladener Operator nicht.



  • 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?

    MFK schrieb:

    Kann es sein, dass deine Verwirrung einfach nur durch diese verschobene Wahrnehmung verursacht wird, möglicherweise weil du sehr lange mit einer Sprache zu tun hattest, die keine Operatorüberladung kennt?

    in der tat, dieser thread startete ja als 'op-überladung in C', was ja bekannterweise dieses zweifelhafte feature nicht hat. weil ich nun mal die meiste zeit in C code, kommt mir op-überladung fremd und blödsinnig vor. in anderen sprachen, in denen gang und gebe ist, dass man sich neue op's definiert, mag das nicht der fall sein. man muss eben immer darauf achten in welcher umgebung man sich befindet. als 3-dimensionales wesen bist du in einem raum ohne türen eingeschlossen. kannst du aber vierdimensional agieren, spazierst du einfach nach draussen. 😉

    lolz schrieb:

    pale dog schrieb:

    Simon2 schrieb:

    Übrigens: Die freie Wahl der Funktionsnamen führt mindestens zu ebensoviel Verwirrung.

    class A {
       int i;
    public:
       int get() { i = 7; return 5; }
       void set(int a) { outFile << a; }
    };
    

    klar, aber ich kann es erkennen, wenn ich den code sehe:
    - die get-funktion setzt i immer auf 7 und gibt immer 5 zurück.
    - die set-funktion shiftet eine variable 'outFile' um 'a' bits nach links.
    die funktionen tun also nicht das, was man bezüglich ihrer namen von ihnen erwarten würde.
    hättest du aber einen der operatoren, das = oder das << überladen, dann würde man schon weniger aussagen über den code machen können:
    - die get-funktion gibt immer 5 zurück
    alles andere bliebe im dunkeln.
    🙂

    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!

    rüdiger schrieb:

    pale dog schrieb:

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

    Und warum interessiert es mich ob ich gerade zwei primitive oder zwei nicht primitive Objekte addiere? Mich interessiert doch nur, dass die Addition statt findet.

    dich interessiert nicht die wirkung der addition bzw. was sich dahinter verbirgt? ich finde schon, dass man es wissen sollte, wenn man es richtig anwenden will. wie willst du sonst z.b. fehlern auf die schliche kommen, wenn du einen wichtigen teil des codes nicht verstehst?



  • Reyx schrieb:

    rüdiger schrieb:

    Und warum interessiert es mich ob ich gerade zwei primitive oder zwei nicht primitive Objekte addiere? Mich interessiert doch nur, dass die Addition statt findet.

    Genau das war ja das Argument: Was man addiert ist nicht fraglich, fraglich ist nur, ob man addiert!

    Und welchen Vorteil bringt dann

    a.add(b);
    

    da weiß ich ja auch nicht ob der addiert.

    pale dog schrieb:

    rüdiger schrieb:

    pale dog schrieb:

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

    Und warum interessiert es mich ob ich gerade zwei primitive oder zwei nicht primitive Objekte addiere? Mich interessiert doch nur, dass die Addition statt findet.

    dich interessiert nicht die wirkung der addition bzw. was sich dahinter verbirgt? ich finde schon, dass man es wissen sollte, wenn man es richtig anwenden will. wie willst du sonst z.b. fehlern auf die schliche kommen, wenn du einen wichtigen teil des codes nicht verstehst?

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

    Und die Wirkung und was sich dahinter verbirgt sind zwei verschiedene Dinge. Mich interessiert erst einmal die Wirkung. Egal ob bei einem Operator oder einer Methode.



  • pale dog schrieb:

    lolz schrieb:

    pale dog schrieb:

    Simon2 schrieb:

    Übrigens: Die freie Wahl der Funktionsnamen führt mindestens zu ebensoviel Verwirrung.

    class A {
       int i;
    public:
       int get() { i = 7; return 5; }
       void set(int a) { outFile << a; }
    };
    

    klar, aber ich kann es erkennen, wenn ich den code sehe:
    - die get-funktion setzt i immer auf 7 und gibt immer 5 zurück.
    - die set-funktion shiftet eine variable 'outFile' um 'a' bits nach links.
    die funktionen tun also nicht das, was man bezüglich ihrer namen von ihnen erwarten würde.
    hättest du aber einen der operatoren, das = oder das << überladen, dann würde man schon weniger aussagen über den code machen können:
    - die get-funktion gibt immer 5 zurück
    alles andere bliebe im dunkeln.
    🙂

    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!

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



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



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

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



  • 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# 👍



  • Generell sollen überladene Operatoren ihrer jeweiligen Funktion entsprechen, und nicht ganz was anderes machen. (+ soll etwas addieren und nicht subtrahieren etc.) Wenn das ein Programmierer nicht berücksichtigt, und Operatoren verfälscht, der ist selber Schuld, und hält sich nicht an das dafür vorgesehene Konzept. Dafür kann C++ nichts. Es bietet einem diese Möglichkeit an, und wenn es dann jemand missbraucht, ist keine Rechtfertigung dafür, dass Operatorüberladung in C++ sinnlos seie.

    pale dog schrieb:

    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.

    Stimmt nicht ganz. Wenn man sich nicht sicher sein sollte, dann soll man den jeweiligen Operator doch direkt aufrufen (Klasse.operator+ (param)).



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



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



  • 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?



  • 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!)



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



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



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



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



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



  • 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?


Anmelden zum Antworten