spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Jo, passende Fälle, wo es Sinn macht, kann man ganz eindeutig konstruieren. Aber um die geht es nicht in der Frage.

Es ist vermutlich wirklich eher eine philosophische Frage. Subjektiv verwende ich immer öfter freie Funktionen; zumal C++ operator-overloading unterstützt. Gerade bei Infix-Operationen greife ich nahezu ausschließlich auf globale Funktionen zurück.

Technisch gesehen, wenn es kein großer Aufwand ist, verwendete ich freie Funktionen. Wenn man diese jedoch erstmal friend deklarieren müsste oder ein zusätzliche Methoden bereitstellen müsste, damit ich auf Gleichheit prüfen könnte, sähe ich davon ab und stellte eine entsprechende Methode zur Verfügung.

Also macht man das, weil man das so macht. Auch wenn's eigentlich für Kapselung kontraproduktiv ist. Weird.

Wieso ist es deiner Meinung nach für die Kapselung kontraproduktiv? Hier nochmal der Link von vorhin: http://www.drdobbs.com/cpp/how-non-membe…capsu/184401197

Abgesehen davon haben freie Funktionen auch Vorteile bezüglich Flexibilität wenn es in Richtung Templates geht, da man nicht auf benutzerdefinerte Typen beschränkt ist, wie es mit Methoden der Fall wäre...

Was den Compiler in gewissen Situationen aber auch schnell verwirren kann. @globale_operatoren_und_templates

MfG
Check

Zitat von »Checkmateing«

Was den Compiler in gewissen Situationen aber auch schnell verwirren kann. @globale_operatoren_und_templates

Was genau meinst du damit?

Zitat von »Koschi«

Wie gesagt Dot der nutzen ist mir vollkommen klar. Ich möchte aber weg von Fallbeispielen wie..

	C-/C++-Quelltext
1 2 3	std::string operator+ (const char* lh, const std::string& rh); // oder Vector2D operator* (const int lh, const Vector2D& rh);

hinzu

	C-/C++-Quelltext
1 2 3 4	// um mal beim Vector zu bleiben Vector2D operator* (const Vector2D& lh, const Vector2D& rh); // oder bool operator< (const Vector2D& lh, const Vector2D& rh);

Also warum hat diese Implementierung Vorteile gegenüber der Methode als Member-Funktion

	C-/C++-Quelltext
1 2 3	Vector2D Vector2D::operator* (const Vector2D& rh); // oder bool Vector2D::operator< (const Vector2D& rh);

Ist es nur ein Philosophische frage oder hat es einen greifbaren technischen Vorteil?

Wie gesagt: Die Variante mit freien Funktionen unterstützt automatisch auch int + Vector2D, sobald Vector2D einen Konstruktor anbietet, der einen int nimmt, du brauchst nicht für alle möglichen Kombinationen separate Operatoren schreiben, alles funktioniert auf völlig natürlich Art und Weise von selbst und vor allem symmetrisch. Die Variante mit Memberfunktionen dagegen kann int + Vector2D rein prinzipiell nicht behandeln, nur Vector2D + int. Falls es immer noch nicht klar ist, hier noch ein Beispiel:

Wenn der Konstruktor auch Templates will unds keine andere Möglichkeit gibt.
z.B.

In so einem Fall muss man die Funktion als MemberFriend implementieren und das auch direkt definieren... Obiges Beispiel kompiliert nicht.


MfG
Check

Das ist aber ein freie Funktion und kein Member. Wobei ich dir recht gebe, ich persönlich betrachte friends auch als eine Art Member. Nur hier geht's um etwas anderes...

Außerdem kompiliert das bei mir sehr wohl...

Wenn man ihn beginnt anzuwenden und evtl. auch ausreizt nicht mehr, was ich nun angefügt habe.

MfG
Check

Zitat von »Checkmateing«

Wenn man ihn beginnt anzuwenden und evtl. auch ausreizt nicht mehr, was ich nun angefügt habe.

Nun, ich würde selbst hier auch auf jeden Fall mit friend arbeiten. Hintergrund dafür ist, dass in der Variante ohne friend eine Instanzierung des Klassentemplate A nicht auch eine Instanzierung des operator + Template erzwingt, weshalb der Compiler dann keinen passenden operator + findet. Aus diesem Grund ist es in der Tat zu empfehlen, im Falle von Templates mit friend zu arbeiten, so wie du es in deinem Beispiel gezeigt hast. Hat aber wie gesagt nichts mit der Frage zu tun, wieso man nun freie Funktionen verwenden soll, denn egal ob mit oder ohne friend, beides ist eine freie Funktion...