Ansi C Operator überladen?

pale dog

Simon2 schrieb:

pale dog schrieb:

CStoll schrieb:

Und der Vorteil der Operator-Überladung ist, daß dir das im Grunde egal sein kann

es kann mir nicht egal sein und es ist mir nicht egal.
ich setze nun mal andere prioritäten.
...

Das hat nicht unbedingt etwas mit Prioritäten zu tun, sondern mit der Komplexität der Programme.

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

Simon2 schrieb:

Systemprogrammierer werden immer stärker von fertige Infrastrukturkomponenten abgelöst. So braucht heute kaum noch jemand wirklich ASM-Erfahrung, immer weiter entwickelte Betriebssyteme übernehmen viele Aufgaben, die früher Systemprogrammierer mit jeweiligen "Selbststricklösungen" erfüllt haben, Remoteprotokolle wie CORBA, RMIIOP, ... machen Netzwerkprogrammierer arbeitslos,

es gibt genug systeme (und es kommen ständig neue auf den markt) für die all dies noch nicht existiert, oder die einfach zu wenig ressourcen haben, um für sie komplette betriebssysteme zu portieren usw., also arbeitslos wird so schnell kein lowlevel-coder.
...und natürlich sollte man nicht selbst nachfrickeln was es schon fertig gibt, sondern bewährtes einsetzen. da bin ich ganz deiner meinung.

btw: nicht dass du denkst, ich würde OOP komplett verteufeln. ich mag eine bestimmte OO-sprache inclusive plattform recht gern (die kennt übrigens keine overloaded-ops) und manchmal programmiere ich sogar noch mit MFC

Mr. N

pale dog schrieb:

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

Womit sonst? Orthogonalität? Das ist jetzt ja nicht die Stärke von C.

pale dog

Mr. N schrieb:

pale dog schrieb:

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

Womit sonst?

modularisierung, schichtenmodelle usw.
etwa das, was Simon2 angesprochen hat, auch wenn er auf etwas anderes hinaus wollte.

Mr. N schrieb:

Orthogonalität? Das ist jetzt ja nicht die Stärke von C.

muss ja auch nicht.
C ist ein nur ein ziemlich 'straightes' werkzeug, es zwingt dir keine konzepte auf.
klar, C's ausstattung ist spartanisch, aber für seinen zweck (system- treiber- kernel- netzwerk- programmierung) ist alles da was man braucht und man hat zugriff auf unmengen an source codes und libraries (google - filetype:c).
ich hab' letztens erst einen freien basic-interpreter in C aus'm netz gezogen, leicht umgebaut und jetzt läuft er als scriptsprache auf einem embedded system

wir sollten jetzt aber keinen flamewar C++ gegen C anfangen, das wäre ja so, als wenn der grosse bruder das kleine geschwisterchen verprügeln würde

Mr. N

pale dog schrieb:

Mr. N schrieb:

pale dog schrieb:

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

Womit sonst?

modularisierung, schichtenmodelle usw.

Ist das keine Komplexität? Wieso ist dann so etwas simples und intuitives wie Operatorüberladung komplex?

Nebenbei, zum Thema "Schichtenmodell"... Das ist dann vermutlich das Zeug, was meine Kollegen gerade abschaffen, nachdem Kollege H das Team gewechselt hat. Irgendein bekannter Softwarezeug-Schreiberling hat gesagt: Schichten sind toll um Diagramme zu zeichnen (mit denen ich irgendwie allerdings nie was anfangen konnte), aber eben nicht flexibel genug für die Anforderungen der Realität.

pale dog schrieb:

Mr. N schrieb:

Orthogonalität? Das ist jetzt ja nicht die Stärke von C.

muss ja auch nicht.
C ist ein nur ein ziemlich 'straightes' werkzeug, es zwingt dir keine konzepte auf.

Das ist auch die große Stärke von C++ .

pale dog schrieb:

klar, C's ausstattung ist spartanisch, aber für seinen zweck (system- treiber- kernel- netzwerk- programmierung) ist alles da was man braucht und man hat zugriff auf unmengen an source codes und libraries (google - filetype:c).

Und man hat den großen Vorteil, dass Linus Torvalds es akzeptiert .

pale dog schrieb:

wir sollten jetzt aber keinen flamewar C++ gegen C anfangen, das wäre ja so, als wenn der grosse bruder das kleine geschwisterchen verprügeln würde

Du willst also lieber Java verteidigen?

CStoll

pale dog schrieb:

Mr. N schrieb:

pale dog schrieb:

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

Womit sonst?

modularisierung, schichtenmodelle usw.
etwa das, was Simon2 angesprochen hat, auch wenn er auf etwas anderes hinaus wollte.

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

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.

Mr. N schrieb:

Orthogonalität? Das ist jetzt ja nicht die Stärke von C.

muss ja auch nicht.
C ist ein nur ein ziemlich 'straightes' werkzeug, es zwingt dir keine konzepte auf.

Macht C++ doch auch nicht.
Wenn du wirklich Low-Level programmieren willst, hindert dich niemand daran, die fortgeschrittenen Möglichkeiten von C++ zu ignorieren - niemand ist gezwungen, Operatoren zu überladen oder alles in Klassen zu verpacken.
(und einen Operator kannst du übrigens genauso durchoptimieren wie jede andere Funktion).

wir sollten jetzt aber keinen flamewar C++ gegen C anfangen, das wäre ja so, als wenn der grosse bruder das kleine geschwisterchen verprügeln würde

Randfrage: Wen siehst du hier als großen Bruder an?

pale dog

Mr. N schrieb:

pale dog schrieb:

klar, C's ausstattung ist spartanisch, aber für seinen zweck (system- treiber- kernel- netzwerk- programmierung) ist alles da was man braucht und man hat zugriff auf unmengen an source codes und libraries (google - filetype:c).

Und man hat den großen Vorteil, dass Linus Torvalds es akzeptiert .

als windoze-user weise ich diese freche unterstellung entschieden zurück

CStoll schrieb:

pale dog schrieb:

Mr. N schrieb:

pale dog schrieb:

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

Womit sonst?

modularisierung, schichtenmodelle usw.
etwa das, was Simon2 angesprochen hat, auch wenn er auf etwas anderes hinaus wollte.

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.

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

CStoll schrieb:

wir sollten jetzt aber keinen flamewar C++ gegen C anfangen, das wäre ja so, als wenn der grosse bruder das kleine geschwisterchen verprügeln würde

Randfrage: Wen siehst du hier als großen Bruder an?

der, der aussieht wie die türkische flagge, bloss mit einem zweiten sternchen drin

Mr. N

pale dog schrieb:

dass es auch sehr gut ohne geht, beweist doch eine der erfolgreichsten OOP-plattformen der welt recht gut.

Welche meinst du? (Ja, du begibst dich damit vermutlich in die Gefahr, einen Flame zu beschwören - aber IMHO ist es jetzt schon zu spät, um das zu bereuen. *teuflischlach*)

pale dog

Mr. N schrieb:

pale dog schrieb:

dass es auch sehr gut ohne geht, beweist doch eine der erfolgreichsten OOP-plattformen der welt recht gut.

Welche meinst du?

dazu sag ich mal nix

Mr. N

pale dog schrieb:

dazu sag ich mal nix

Also Java.

pale dog

Mr. N schrieb:

pale dog schrieb:

dazu sag ich mal nix

Also Java.

damit hast du das todesurteil für diesen thread ausgesprochen.

Mr. N

pale dog schrieb:

damit hast du das todesurteil für diesen thread ausgesprochen.

Du hast diese Sprache als Beispiel dafür gebracht, wieso man keine Operator-Überladung braucht. Was man ja auch an der Vielzahl an Matrix-Bibliotheken für Java sieht...

pale dog

Mr. N schrieb:

pale dog schrieb:

damit hast du das todesurteil für diesen thread ausgesprochen.

Du hast diese Sprache als Beispiel dafür gebracht, wieso man keine Operator-Überladung braucht....

das hat nichts zu bedeuten.
die meisten sprachen kommen ohne operatorüberladung aus.
ausserdem hab' ich java auch schon (indirekt) weiter oben erwähnt, weil ich damit klarstellen wollte, dass ich kein genereller OOP-hasser bin, denn den eindruck, glaube ich, bei einigen erweckt zu haben.
ausserdem - obwohl ich hier allein gegen eine ganze armee von op-überladungsfreaks stehe - wollen wir ja nicht noch die Java-fans anlocken.
wenn die erst kommen, dann zieht ihr nämlich den kürzeren

Mr. N

pale dog schrieb:

Mr. N schrieb:

pale dog schrieb:

damit hast du das todesurteil für diesen thread ausgesprochen.

Du hast diese Sprache als Beispiel dafür gebracht, wieso man keine Operator-Überladung braucht....

das hat nichts zu bedeuten.
die meisten sprachen kommen ohne operatorüberladung aus.

Jo, Brainfuck braucht das auch nicht.

pale dog schrieb:

ausserdem hab' ich java auch schon (indirekt) weiter oben erwähnt, weil ich damit klarstellen wollte, dass ich kein genereller OOP-hasser bin, denn den eindruck, glaube ich, bei einigen erweckt zu haben.

Die Operator-Überladungs-Freunde sind denke ich zumeist keine OOP-Dogmatiker sondern Anhänger des in C++ üblichen Mischens von Paradigmen.

pale dog schrieb:

ausserdem - obwohl ich hier allein gegen eine ganze armee von op-überladungsfreaks stehe

"Ein Geisterfahrer?! Hunderte!"

pale dog schrieb:

- wollen wir ja nicht noch die Java-fans anlocken.

Jo, die sind die schlimmsten.

pale dog schrieb:

wenn die erst kommen, dann zieht ihr nämlich den kürzeren

Weil sie noch weniger diskussionsbereit sind, als Jester es von mir behauptet?

Oder weil sie in der Überzahl sind?

... Natürlich nicht, weil sie potenziell Recht haben könnten, das stimmt natürlich mal gar von sowas nicht.

rüdiger

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

pale dog

Mr. N schrieb:

pale dog schrieb:

ausserdem hab' ich java auch schon (indirekt) weiter oben erwähnt, weil ich damit klarstellen wollte, dass ich kein genereller OOP-hasser bin, denn den eindruck, glaube ich, bei einigen erweckt zu haben.

Die Operator-Überladungs-Freunde sind denke ich zumeist keine OOP-Dogmatiker sondern Anhänger des in C++ üblichen Mischens von Paradigmen.

wirklich? ich dachte dass für C++ fans gerade das op-overloading etwas ist, durch das C++'s OO-fähigkeit erst richtig komplett wird

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.

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.