Ansi C Operator überladen?

[rüdiger]

pale dog schrieb:

rüdiger schrieb:

pale dog schrieb:

die meisten sprachen kommen ohne operatorüberladung aus.

Es gibt auch Sprachen die kommen ohne Variablen und ohne Operatoren aus. Ich weiß nur nicht ob man das deswegen in anderen Sprachen genauso machen sollte...

das sind aber ziemlich exotische sprachen.
es gibt da ja alles mögliche, programmiersprachen ohne jegliche kontrollstrukturen, programmiersprachen in denen man bilder malt anstatt code zu schreiben, programmiersprachen als ersatz für schaltschrankverdrahtung usw.usw.usw...
trotzdem gibt es viele nicht-exotensprachen, ohne solche exotenfeatures wie operatorüberladung, die täglich millionenfach genutzt werden und wobei keinem der gedanke kommt, dass op-overloading auch nur ansatzweise fehlen würde.

Was ich dir sagen wollte war, dass Programmiersprachen unterschiedlich sind. Was in einer Programmiersprache funktioniert oder richtig ist, muss nicht für eine andere Programmiersprache richtig sein.

Argumente ala "Aber X tut das so. Also soll Y das auch so tun" sind lächerlich.

("Und wenn X von der Brücke springt, würdest du das auch tun?...")

[Mr. N]

pale dog schrieb:

das sind aber ziemlich exotische sprachen.

Ist diese Unterscheidung in irgendwie wichtig?

pale dog schrieb:

es gibt da ja alles mögliche, programmiersprachen ohne jegliche kontrollstrukturen, programmiersprachen in denen man bilder malt anstatt code zu schreiben, programmiersprachen als ersatz für schaltschrankverdrahtung usw.usw.usw...

Und die letzte ist sogar ernst gemeint, vermute ich.

pale dog schrieb:

trotzdem gibt es viele nicht-exotensprachen, ohne solche exotenfeatures wie operatorüberladung

Operatorüberladung ist kein Exotenfeature.

pale dog schrieb:

, die täglich millionenfach genutzt werden und wobei keinem der gedanke kommt, dass op-overloading auch nur ansatzweise fehlen würde.

Lisp braucht auch keine Operator-Überladung. Weil es keine Operatoren gibt.

Und bei den anderen: Dir ist schon bewusst, dass das Forum überfüllt ist mit Fragen wie "Welche Befehle hat C++?" oder "Welchen Befehl brauche ich, um einen Kreis zu malen? Ach ja und ein Fenster will ich auch noch."...? Diese Leute sind natürlich keine Fans der Operator-Überladung. Das ist ganz einfach nicht auf ihrem Radar.

Wer Operator-Überladung nicht kennt, wird sie auch nicht vermissen. Der wird eben mit x1.add(x2) rumfrickeln und sich vielleicht sogar ärgern, warum seine einfache Formel so schwer umzusetzen ist (übrigens eine Aufgabe, die keineswegs alltäglich ist - aber sie kommt vor). Er wird aber nicht unbedingt gleich darauf kommen: "Wenn ich den Operator jetzt überladen könnte..."

[Hazzel]

Was spricht da gegen:

Ich sehe einen Datentyp gerne "von oben". Was eine Zahl darstellen kann, soll auch rechnen können - da habe ich keine Lust, mein komplettes Programm umzustellen, nur weil mir long zu klein wurde und ich deshalb umsteige auf eine eigene BigInt-Klasse. Mit dem jetzigen Konzept reicht es aus, einen typedef zu ändern und dank Operator-Überladung kann ich die BigInt's ohne weitere Quellcode-Änderungen nutzen. Ohne diese Möglichkeit müsste ich alle Formeln in meinem Programm umstellen zu mehrfach verschachtelten Funktionsaufrufen.

Ich verstehe die Anti-Operator-Überladungs-Argumentation irgendwie nicht.
Das tolle ist ja, das z.B. ein "+" Operator genau das tut, was er soll. Addieren halt. Bei Funktionen ist das imho nicht immer so eindeutig.

[Simon2]

pale dog schrieb:

...komplexität bezwingt man aber nicht mit zusätzlicher komplexität. ;)...

Korrekt !
Deswegen sollte man nicht die Komplexität der semantischen Mittel erhöhen, indem man Indexzugriffe plötzlich nicht mehr per [], sondern per Makro (oder eine Funktion mit einem Namen seines persönlichen Geschmacks) vornimmt.
"Kapselung" bedeutet: Sehen, WAS gemacht wird, ohne genau wissen zu müssen, WIE es die benutzte Schicht es umsetzt. Damit begrenzt man Komplexität - und dabei hilft (Oh Wunder) Operatorüberladung.

Wenn Du so ein Herz für neue Plattformen hast, müsstest Du es doch kennen, dass man auf Basis einer bestimmten API, mit der man sich erstmal vertraut machen muss, programmiert. Und da wird Dich doch nicht plötzlich ein überladener operator[]() aus der Fassung bringen, oder ?

Auf einem neuen System kannst Du sowieso nicht davon ausgehen, dass ein Indexzugriff "hinter den Kulissen" (was für Dich anscheinend Maschinenebene bedeutet) genauso funktioniert, wie Du es bislang gewohnt bist. Du musst es Dir also (wenn Du es wissen willst) sowieso ansehen.

@"...freunde": Sorry, aber das sind nun wirklich die Kollegen, die alle C++-Features ablehnen, die sie nicht kennen, WEIL sie sie nicht kennen. "Wieso - geht doch auch ohne !" ... hat mir damals ein ASM-Fan gesagt, als er von OO hörte - mit übrigens genau denselben Argumenten wie Du
- Dann sehe ich ja gar nicht mehr, was da passiert
- das macht das alles nur komplizierter
- Habe ich noch nie gebraucht
- das kann man alles auch ohne machen.

Gruß,

Simon2.

[Simon2]

Hazzel schrieb:

Was spricht da gegen:

Ich sehe einen Datentyp gerne "von oben". Was eine Zahl darstellen kann, soll auch rechnen können - da habe ich keine Lust, mein komplettes Programm umzustellen, nur weil mir long zu klein wurde und ich deshalb umsteige auf eine eigene BigInt-Klasse. Mit dem jetzigen Konzept reicht es aus, einen typedef zu ändern und dank Operator-Überladung kann ich die BigInt's ohne weitere Quellcode-Änderungen nutzen. Ohne diese Möglichkeit müsste ich alle Formeln in meinem Programm umstellen zu mehrfach verschachtelten Funktionsaufrufen.

Ich verstehe die Anti-Operator-Überladungs-Argumentation irgendwie nicht.
Das tolle ist ja, das z.B. ein "+" Operator genau das tut, was er soll. Addieren halt. Bei Funktionen ist das imho nicht immer so eindeutig.

Versuch es gar nicht erst, das hört pale schon seit 10 Threadseiten - er ignoriert es einfach oder führt plötzlich Performanceargumente an (sehr interessant für einen Freund der Sprache, "deren Namen nicht genannt werden darf" ).

Gruß,

Simon2.

[pale dog]

rüdiger schrieb:

Was ich dir sagen wollte war, dass Programmiersprachen unterschiedlich sind. Was in einer Programmiersprache funktioniert oder richtig ist, muss nicht für eine andere Programmiersprache richtig sein.

da stimme ich dir zu.
aber es ist nunmal so, dass die meisten programmiersprachen von leuten entwickelt werden, die auch viele andere sprachen kennen. in ihrer euphorie (und deshalb leider kurzsichtigkeit) gucken sie sich sachen von einer anderen sprache ab, weil sie sie einfach nur 'cool' finden.
doch manchmal ist weniger eben mehr...

Mr. N schrieb:

Wer Operator-Überladung nicht kennt, wird sie auch nicht vermissen.
[...]
Er wird aber nicht unbedingt gleich darauf kommen: "Wenn ich den Operator jetzt überladen könnte..."

...würde er sich sicher ein zweites loch in den po freuen, das glaube ich auch.
aber um so grösser wär' wahrscheinlich der frust, wenn er nach ein paar wochen seinen eigenen code nicht mehr versteht. die korrekte anwendung von overloaded-ops ist nicht einfach. ich denke dafür braucht man viel erfahrung.

btw:
hey leute, wir drehen uns seit längerem nur noch im kreis. ich steige jetzt wirklich aus
~(jaja, das hat dieser idiot vorgestern auch schon gesagt)~
und betet, dass die java-fans nicht hier auftauchen

[Mr. N]

pale dog schrieb:

ich denke dafür braucht man viel erfahrung.

Eigentlich nicht. Man braucht um C++ gut einzusetzen allgemein viel Erfahrung, aber Operator-Überladung ist da kein großes Problem. Solange man sich erstmal von operator&&, operator, und Konsorten fernhält (welche das sind, steht in jedem guten C++-Buch). Aber das ist machbar.

pale dog schrieb:

btw:
hey leute, wir drehen uns seit längerem nur noch im kreis. ich steige jetzt wirklich aus

Jetzt hatte ich doch gehofft, dich durch gebetsmühlenhafte Diskussion zu bekehren.

pale dog schrieb:

~(jaja, das hat dieser idiot vorgestern auch schon gesagt)~
und betet, dass die java-fans nicht hier auftauchen

Hätten die doch längst, wenn sie was zu sagen hätten .

[rüdiger]

pale dog schrieb:

rüdiger schrieb:

Was ich dir sagen wollte war, dass Programmiersprachen unterschiedlich sind. Was in einer Programmiersprache funktioniert oder richtig ist, muss nicht für eine andere Programmiersprache richtig sein.

da stimme ich dir zu.
aber es ist nunmal so, dass die meisten programmiersprachen von leuten entwickelt werden, die auch viele andere sprachen kennen. in ihrer euphorie (und deshalb leider kurzsichtigkeit) gucken sie sich sachen von einer anderen sprache ab, weil sie sie einfach nur 'cool' finden.
doch manchmal ist weniger eben mehr...

Was in einer Programmiersprache funktioniert oder richtig ist, muss nicht für eine andere Programmiersprache richtig sein.

(komisch ich glaube ich habe das schon mal gesagt)

[Zeus]

Nur schade ist, dass bei allen anderen Sprache die zur Zeit entwickelt werden immer mehr Feature kommen, wie C++, C#, Java, Python etc.

[Bashar]

Das ist jetzt aber albern. Wie stellst du dir das vor, sollen es vielleicht weniger Features werden?

[Zeus]

Albern wieso? Pale meinte "Weniger ist mehr", aber mit der Entwicklung der Sprache kömmen immer mehr, beispielsweise C# 1.0, da hatte keine Generics, keine Operatorenüberladung etc oder Java im JDK 7 kommen anscheinend Operatorenüberladung, Superpackage, etc etc etc.

[CStoll]

pale dog schrieb:

Und hat (z.B.) Modularisierung mit Operator-Überladung zu tun?

kann sein, aber ich glaube struppi hat op-überladung eher eingebaut, weil er es 'geil' fand. dass es auch sehr gut ohne geht, beweist doch eine der erfolgreichsten OOP-plattformen der welt recht gut.

Selbst wenn das so wäre, es hat seinen Zweck erfüllt. Und wieso sollte ein Ausdruck ala "x = A*y + c" schwieriger zu warten oder zu verstehen sein als "assign_vec(x,sum_vec(prod_mat_vec(A,y),c))" (so in etwa würde die obige Formel aussehen, wenn du keine Operatoren überladen könntest)?

CStoll schrieb:

Wenn du wirklich Low-Level programmieren willst, hindert dich niemand daran, die fortgeschrittenen Möglichkeiten von C++ zu ignorieren

versuche ich ja, aber C++ weigert sich vehement: hast du schon mal probiert, bestehende C-codes durch einen C++ compiler zu jagen? das hagelt nur so von errors...

Daß C++ Compiler in vieler Hinsicht strenger sind als C Compiler, ist (hoffentlich) allgemein bekannt - und Bestandteil des C++ Standards. Aber trotzdem laufen die meisten C-Programme auch unter C++ mit lediglich kleinen Anpassungen (von einigen Sonderregeln wie impliziten Typangaben oder -Umwandlungen (void* -> normaler Zeiger) mal abgesehen).

auch wenn man mal im C++ forum einen quelltext ohne 'std::wassweissich' posted, gibt's gleich mecker von allen seiten: 'das ist aber kein C++, *heul*, *kreisch*'

Das ist aber wirklich übertrieben dargestellt. Bemerkungen ala "das ist kein C++" kommen erst, wenn jemand die unsicheren C-Funktionen (scanf/printf oder char*-Verarbeitung) in C++ einsetzen will (und dann normalerweise nur als Hinweis darauf, daß cin/cout bzw. std::string zur Verfügung stehen).

pale dog schrieb:

die korrekte anwendung von overloaded-ops ist nicht einfach. ich denke dafür braucht man viel erfahrung.

Ja, das "korrekte" Schreiben von überladenen Operatoren hat so einige Tücken - ihre Anwendung in einem größeren Zusammenhang ist dagegen recht einfach und intuitiv

[Simon2]

pale dog schrieb:

...
versuche ich ja, aber C++ weigert sich vehement: hast du schon mal probiert, bestehende C-codes durch einen C++ compiler zu jagen? das hagelt nur so von errors...

Schon lustig: Da warnt einen der Compiler, dass man etwas Unsicheres/Gefährliches/Dummes/Falsches/... tun will und der Programmierer beschwert sich !

pale dog schrieb:

...
auch wenn man mal im C++ forum einen quelltext ohne 'std::wassweissich' posted, gibt's gleich mecker von allen seiten: 'das ist aber kein C++, *heul*, *kreisch*'
...

Könnte auch was damit zu tun haben, dass die Threads meistens überschrieben sind mit "Anfängerfrage: Wieso bekomme ich bei meinem non-C++-530-Zeilen-Rumfrickel-Programm einen Segfault ? (und Wieso funktioniert die elegante 5-Zeilen-C++-Variante problemlos ?)"

Gruß,

Simon2.

[pale dog]

ihr habt mich jetzt so oft zitiert und deshalb will ich euch doch noch mal antworten:

rüdiger schrieb:

pale dog schrieb:

rüdiger schrieb:

Was ich dir sagen wollte war, dass Programmiersprachen unterschiedlich sind. Was in einer Programmiersprache funktioniert oder richtig ist, muss nicht für eine andere Programmiersprache richtig sein.

da stimme ich dir zu.
aber es ist nunmal so, dass die meisten programmiersprachen von leuten entwickelt werden, die auch viele andere sprachen kennen. in ihrer euphorie (und deshalb leider kurzsichtigkeit) gucken sie sich sachen von einer anderen sprache ab, weil sie sie einfach nur 'cool' finden.
doch manchmal ist weniger eben mehr...

Was in einer Programmiersprache funktioniert oder richtig ist, muss nicht für eine andere Programmiersprache richtig sein.

ja, wie gesagt, volle zustimmung.
ich finde aber, das solltest du eher den leuten sagen, die fröhlich konzepte verschiedenster sprachen mischen und dabei unnötig komplizierte und verworrene gebilde herauskommen.
nicht dass ich ihnen böse absicht unterstellen will, sie finden es toll, keine frage, doch das ist wie mit einigen handys: designed von technikbegeisterten ingenieuren, aber den endbenutzern qualmen regelmässig die köpfe, wenn sie sich durch's menu klickern müssen

Zeus schrieb:

Albern wieso? Pale meinte "Weniger ist mehr"

ich meinte es so, dass jegliche erweiterung wohlüberlegt sein muss. hinterher kann bzw. sollte man nichts mehr rausschmeissen.

CStoll schrieb:

Aber trotzdem laufen die meisten C-Programme auch unter C++ mit lediglich kleinen Anpassungen (von einigen Sonderregeln wie impliziten Typangaben oder -Umwandlungen (void* -> normaler Zeiger) mal abgesehen).

es kommt auf die menge des codes an. ein grosses C-projekt mit einem C++ compiler fehlerfrei zu compilieren ist sehr aufwendig. dazu haben sich die beiden sprachen im laufe der zeit zu weit voneinander entfernt.

CStoll schrieb:

pale dog schrieb:

die korrekte anwendung von overloaded-ops ist nicht einfach. ich denke dafür braucht man viel erfahrung.

Ja, das "korrekte" Schreiben von überladenen Operatoren hat so einige Tücken - ihre Anwendung in einem größeren Zusammenhang ist dagegen recht einfach und intuitiv

naja, ich meinte beides. schreiben eines sehr guten, intuitiven, maximal funktionierenden, niemals herumzickenden usw, overloaded-op's ist schwierig.
...und beim anwenden sollte man sich dessen bewusst sein, dass overloaded-op's im spiel sind

Simon2 schrieb:

pale dog schrieb:

...
versuche ich ja, aber C++ weigert sich vehement: hast du schon mal probiert, bestehende C-codes durch einen C++ compiler zu jagen? das hagelt nur so von errors...

Schon lustig: Da warnt einen der Compiler, dass man etwas Unsicheres/Gefährliches/Dummes/Falsches/... tun will und der Programmierer beschwert sich !

nein, ein C++ compiler muckt sogar bei C-codes die tausendfach getestet, seit jahren im einsatz sind und bei denen 'lint' nicht eine warnmeldung ausspucken würde.
C und C++ sind zwei eigenständige sprachen, das solltest du dir mal klar machen.

[Simon2]

pale dog schrieb:

...C und C++ sind zwei eigenständige sprachen, das solltest du dir mal klar machen.

Das ist mir absolut klar !
Trotzdem hat es einen GRUND, warum für C++ ein stärkeres Typsystem gegenüber C eingführt wurde ... und damit hat es auch einen Grund, warum, ein C++-Compiler da etwas anmeckert, was in C problemlos erlaubt war (ein C++-char* ist halt nicht dasselbe wie ein C-char* ... ersteres gibt eine höhere "Garantie").

Ich finde es tatsächlich ein wenig amüsant, dass Du ein "etwas anderer Javafan" bist ... die meisten (die mir begegenet sind) kennen nämlich nur die Schwächen von C und werfen sie C++ vor (auch da, wo sie bereits ausgebügelt oder zumindestens "deprecated" sind) - Du scheinst aber einerseits "C-Schrauber" (nicht bös' gemeint) und gleichzeitig "Java-OO-Highlevler" zu sein - interessant.

Gruß,

Simon2.

[CStoll]

*erstaunlich, er ist immer noch da :D*

CStoll schrieb:

Aber trotzdem laufen die meisten C-Programme auch unter C++ mit lediglich kleinen Anpassungen (von einigen Sonderregeln wie impliziten Typangaben oder -Umwandlungen (void* -> normaler Zeiger) mal abgesehen).

es kommt auf die menge des codes an. ein grosses C-projekt mit einem C++ compiler fehlerfrei zu compilieren ist sehr aufwendig. dazu haben sich die beiden sprachen im laufe der zeit zu weit voneinander entfernt.

OK, da hast du meine Zustimmung. Portierung von C nach C++ könnte schwierig werden. Aber niemand zwingt dich, ein Programm mit 2 Millionen LOC nach C++ zu portieren - solange es läuft und du damit zufrieden bist, kannst du es so lassen.

CStoll schrieb:

pale dog schrieb:

die korrekte anwendung von overloaded-ops ist nicht einfach. ich denke dafür braucht man viel erfahrung.

Ja, das "korrekte" Schreiben von überladenen Operatoren hat so einige Tücken - ihre Anwendung in einem größeren Zusammenhang ist dagegen recht einfach und intuitiv

naja, ich meinte beides. schreiben eines sehr guten, intuitiven, maximal funktionierenden, niemals herumzickenden usw, overloaded-op's ist schwierig.
...und beim anwenden sollte man sich dessen bewusst sein, dass overloaded-op's im spiel sind

Du hast es immer noch nicht kapiert (oder vielleicht willst du es gar nicht kapieren). Für den Anwender kann es egal sein, ob er jetzt einen eingebauten Operator oder überladenen Operator verwendet - mit einem BigInt kannst du genauso rechnen wie mit einem int und auf vector<>-Elemente kannst du genauso per [] zugreifen wie auf Array-Elemente.
(das nennt sich "Abstraktion" Für mich ist nur wichtig, daß ich einen Ganzzahl-Typ bzw. eine sequentielle Folge von Werten habe - da will ich mich nicht darum kümmern, was sich dahinter verbirgt)

Simon2 schrieb:

pale dog schrieb:

...
versuche ich ja, aber C++ weigert sich vehement: hast du schon mal probiert, bestehende C-codes durch einen C++ compiler zu jagen? das hagelt nur so von errors...

Schon lustig: Da warnt einen der Compiler, dass man etwas Unsicheres/Gefährliches/Dummes/Falsches/... tun will und der Programmierer beschwert sich !

nein, ein C++ compiler muckt sogar bei C-codes die tausendfach getestet, seit jahren im einsatz sind und bei denen 'lint' nicht eine warnmeldung ausspucken würde.

Nur weil etwas durch den Compiler geht, ist es noch lange nicht fehlerfrei (und wie gesagt, C++ ist in manchen Angelegenheiten etwas strenger als C)

C und C++ sind zwei eigenständige sprachen, das solltest du dir mal klar machen.

die aber immer noch gemeinsame Wurzeln haben

[Bashar]

Zeus schrieb:

Albern wieso?

Weil es gar nicht anders geht. Features wegnehmen kann man nicht, bestehende radikal verändern auch nicht. Wenn man also überhaupt etwas verändern will, kann man nur entweder eine neue Sprache designen, oder Features hinzufügen.
Ersteres geht auch desöfteren schief, siehe Java.

[Zeus]

Geht schon, ob es sinnvoll ist ne andere Sache.

[pale dog]

CStoll schrieb:

pale dog schrieb:

naja, ich meinte beides. schreiben eines sehr guten, intuitiven, maximal funktionierenden, niemals herumzickenden usw, overloaded-op's ist schwierig.
...und beim anwenden sollte man sich dessen bewusst sein, dass overloaded-op's im spiel sind

Du hast es immer noch nicht kapiert (oder vielleicht willst du es gar nicht kapieren). Für den Anwender kann es egal sein, ob er jetzt einen eingebauten Operator oder überladenen Operator verwendet - mit einem BigInt kannst du genauso rechnen wie mit einem int und auf vector<>-Elemente kannst du genauso per [] zugreifen wie auf Array-Elemente.
(das nennt sich "Abstraktion" Für mich ist nur wichtig, daß ich einen Ganzzahl-Typ bzw. eine sequentielle Folge von Werten habe - da will ich mich nicht darum kümmern, was sich dahinter verbirgt)

deine sichtweise ist mir klar und die verstehe ich auch.
[*] ...aber ich glaube eher, du verstehst meine nicht.
in 'meiner welt', in der es manchmal auf taktzyklen und jedes einzelne byte ankommt, ist es sehr oft von bedeutung, wie etwas unter der haube funktioniert.
ich kann nicht alles aus der vogelperspektive betrachten. würde ich das tun, dann könnte ich vielleicht jede zweite software kurz vor'm ende einstampfen, weil sie nicht die geforderte leistung bringt, zuviel RAM verbrät oder der code erst gar nicht in den speicher passt!

[*] deshalb sach' ich ja auch, dass wir uns im kreis drehen...

[CStoll]

pale dog schrieb:

[*] ...aber ich glaube eher, du verstehst meine nicht.
in 'meiner welt', in der es manchmal auf taktzyklen und jedes einzelne byte ankommt, ist es sehr oft von bedeutung, wie etwas unter der haube funktioniert.

Wie ich schon mehrfach versucht habe, dir zu erklären, zwingt dich niemand, Operator-Überladung zu nutzen (oder überhaupt etwas komplizierteres als POD-Typen). Aber wenn du etwas optimieren willst, solltest du vielleicht in den Operatoren ansetzen, anstatt dich über ihre Existenz zu beschweren (und wenn du dich für das wie interessierst, mußt du auf jeden Fall in den Quelltext schauen - ob das Ding nun operator+ genannt wird oder sum(), spielt da auch keine Rolle mehr). C++ kann aus beiden Richtungen betrachtet werden - und beide haben ihre Daseinsberechtigung

ich kann nicht alles aus der vogelperspektive betrachten. würde ich das tun, dann könnte ich vielleicht jede zweite software kurz vor'm ende einstampfen, weil sie nicht die geforderte leistung bringt, zuviel RAM verbrät oder der code erst gar nicht in den speicher passt!

Schön für dich (btw, ich schließe mich Simon's letzter Bemerkung an - wie kommt jemand mit deiner Optimierungs"sucht" zu Java?), aber glücklicherweise schreibt nicht jeder hier Mikro-Prozessor-Programme Und außerdem können Operatoren genauso gut (oder schlecht) bis auf das letzte Byte durchoptimiert werden wie Zugriffsfunktionen, sind also auch kein Hindernis für jemanden, der an den Grenzen seines Systems arbeitet.