spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Andere Kapselung und sich vor der Neukompilierung drücken.
EDIT: und natürlich das, was David unter mir gepostet hat.

MfG
Check

http://stackoverflow.com/questions/11450…member-operator

David: Das trifft hier nicht zu, da beide Operanden vom selben Typ sind. Das war integraler Bestandteil der Frage. Generell gilt in jedem C++ Guide, dass man eine non-member-Variante machen sollte, wenn beide Operanden vom selben Typ sind und man keinen Zugriff auf private Member braucht.
Mir ist aber auch nicht so ganz klar warum. Kapselung sehe ich irgendwie nicht als passend, denn eigentlich tut man ja das Gegenteil - man lagert eine Operation aus, die eigentlich nur diese Klasse betrifft - irgendwie doch kontrovers.
Neukompilierung ist auch ein schlechtes Argument, denn kompilieren muss man so oder so.
Also warum empfehlen es alle Guides?

Laurent hebt sogar extra hervor, dass sie nicht Member sind.
Weder sinnvoll für implizite Konvertierung in dem Fall noch sonst was. Sehr suspekt.
@Cobold: Das mit der Kapselung war mehr Troll/äußerst kurz gedacht. std::string implementiert den operator< ja nicht "von selbst", man muss string einbinden, wo es kürzlich, wenn ich das nun nicht verwechsle, ja auch den schönen Fall gab, dass das bei der Implementierung einer std::map mit std::string als Key nicht funktionierte, weil der opertaor< nicht gefunden wurde. In der Art dachte ich daran. *face->desk*
hm.

MfG
Check

Ein weiterer Grund – abgesehen davon, dass freie Funktionen prinzipiell zu bevorzugen sind (http://www.drdobbs.com/cpp/how-non-membe…capsu/184401197) – ist, dass bei der Variante mit der freien Funktion für beide Operanden implizite Konvertierungen berücksichtigt werden, während bei einer Implementierung als Memberfunktion nur der rechte Operand konvertiert werden kann. Wäre beispielsweise der operator + für std::string als Memberfunktion implementiert, so könnte man string + "blub" schreiben, aber nicht "blub" + string...

Die implizite Konvertierung ist hier aber auch recht sinnfrei und in vielen anderen Fällen vermutlich ebenfalls. Implizite Konvertierungen sind außer bei sehr trivialen Datentypen ja doch eher selten (zumindest, wenn es == betrifft und man eben nicht-mathematische Dinge vergleicht, was außerhalb der Spiele-Entwicklung irgendwie immer der Fall ist). Bisher fehlt mir daher für diese Richtlinie doch irgendwie noch der Aha-Effekt. Sicher, all die Punkte, die ihr ansprecht, haben ihre Berechtigung. Aber eben nur in sehr speziellen Umständen.

Zitat von »Koschi«

Dot: Dein Beispiel mit "Blub" + String hingt auch wieder, weil "Blub" ja kein String wäre. Das man so was braucht ist mir bewusst, aber ich hatte gefragt warum man es bei Operatoren macht wo beide Operanden der gleichen Klasse angehören.

Das ist ja gerade der Punkt. "blub" ist kein std::string, std::string hat aber einen Konstruktor, der ein char Array nimmt, d.h. es existiert eine implizite Umwandlung von char Array nach std::string, welche der Compiler bei der Variante mit der freien Funktion verwenden kann...