Frage zur überladung von Operatoren

volkard

Gibt es bei dir Fälle, in denen du eine Überladung der BuiltIn-Operatoren benötigt hättest? Natürlich. Zu Meßzwecken.
Ich kann mir außerdem gut vorstellen, daß es zur Firmenpolitik gehört, daß keine versehentlichen Interger-Überläufe geschehen dürfen. Mit der Erlaubnis, diese Operatoren zu überladen, könnte man das absichern.

Nexus

volkard schrieb:

Ich kann mir außerdem gut vorstellen, daß es zur Firmenpolitik gehört, daß keine versehentlichen Interger-Überläufe geschehen dürfen. Mit der Erlaubnis, diese Operatoren zu überladen, könnte man das absichern.

Das wäre sicher nicht schlecht. Aber die skalaren Typen haben auch sonst einige Unsicherheiten, zum Beispiel die implizite Konvertierung. Oder die Vermischung von unsigned und signed , die auch darunter fällt.

Es scheint vielleicht umständlich, aber in Fällen, wo solche Dinge wirklich wichtig sind, wäre doch das Naheliegendste, die Typen über Klassen zu wrappen und eigene Semantiken zu implementieren...?

volkard

Nexus schrieb:

Es scheint vielleicht umständlich, aber in Fällen, wo solche Dinge wirklich wichtig sind, wäre doch das Naheliegendste, die Typen über Klassen zu wrappen und eigene Semantiken zu implementieren...?

Auch damit habe ich experimentiert. Aber ich hatte es nichtmal Ansatzweise geschafft, das durchzuhalten. Dauernd will die WinAPI dann doch Zeiger auf elementare Typen und so. Oder C++ selber mag bestimmte Typen, zum Beispiel als Arrayindex. Wird man dann schwach und macht

int Int::operator int()

weicht man sein Konzept wieder auf und kommt in Teufels Küche.

Nexus

Hmm, stimmt, das ist schwer konsequent durchzuziehen. Gerade auch wenn man mit bestimmten Schnittstellen (z.B. von externen Bibliotheken, aber auch der StdLib) zusammenarbeitet, muss man trotzdem immer wieder die skalaren Typen verwenden. Ein ständiges ToInt() oder ähnliches ist auf Dauer wahrscheinlich zu ätzend, auch wenn es wohl die sicherste Möglichkeit darstellt.

Was man tun könnte, ist nur für die "kritischen" Fälle – vor allem bei komplexeren Berechnungen, wo schnell Überläufe passieren – zu solchen Hilfsmitteln zu greifen. Bibliotheken wie Boost.Numeric/Conversion unterstützen einen ebenfalls im Kampf gegen solche Fehler.

Ich denke, Stroustrups Entscheid ist schon nicht ganz so daneben. Klar hätte es ein paar nette Vorteile, selbst zu überladen, aber im Vergleich zu den dadurch entstehenden Problemen scheinen die mir nicht sehr relevant. Ich will mir nicht vorstellen, wie sehr man beim Debugging verzweifeln kann, wenn einfache Anweisungen wie 3 + 5 nicht mehr nachvollziehbar sind...

volkard

Nexus schrieb:

Ich denke, Stroustrups Entscheid ist schon nicht ganz so daneben.

Denke ich auch.
Ich stelle mir nur mal vor, ich überlade den op+(int,int), damit er Überläufe assertet und inkludiere tollelib/tools/random.hpp, aua!
so eine überladung wäre auch irgendwie wie die redefinierung des globalen new() und müßte überall ziehen, oder? aber das wird nix, denn die ganzen anderen übersetzungseinheiten, wissen davon erstmal nichts. alles ganz komisch und ist wohl den aufwand nicht wert.

camper

Nur so ein Gedanke nebenbei. Angenommen wir könnten z.B.

int operator+(int, int) { ... }

schreiben. Wie würden wir eigentlich den Funktionskörper zu schrieben haben ohne uns in Rekursion zu verlieren?

drakon

camper schrieb:

Nur so ein Gedanke nebenbei. Angenommen wir könnten z.B.
int operator+(int, int) { ... }
schreiben. Wie würden wir eigentlich den Funktionskörper zu schrieben haben ohne uns in Rekursion zu verlieren?

Auf Bitmanipulation? Inline Assembler?

Nexus

Das war auch einer meiner Kritikpunkte (wenn auch eher angedeutet). Mir fielen da wie gesagt Operationen ein, die mehr "Low-Level" wären, aber das kann ja nicht der Weisheit letzter Schluss sein...

Edit: Das ist eben das Problem:

drakon schrieb:

Auf Bitmanipulation?

Wenn die entsprechenden Operatoren auch überladen sind?

drakon schrieb:

Inline Assembler?

Nicht wirklich plattformunabhängig.

camper

drakon schrieb:

Auf Bitmanipulation?

und wenn die auch überladen werden?

Inline Assembler?

Was letztlich undefiniertes Verhalten bedeutet, denn die abstrakte Maschine für C++ kennt keinen Assembler. Halte ich daher für keinen günstigen Ausweg.

drakon

Klar, WENN.
Aber ich habe nicht die Überladung von + unterstützt, sondern lediglich Alternativen genannt. Ob das so viel Sinn macht sei dahingestellt.