Ich zweifle im Moment sehr an meinen Konzepten, was eine Memberfunktion sein sollte und was nicht.

Klar, alles was über Zugriff auf Interna verfügen muss oder mit Zugriff auf diese signifikant performanter implementiert werden kann, muss als Memberfunktion geschrieben werden. Das gleiche gilt für Konstruktoren/Destruktoren und einige Operateorenüberladungen.

Im Gegenzug sollte man die meisten ansderen Operatoren frei überladen und Algorithmen, die sich recht generisch auch auf andere Typen anwenden lassen, auch frei implementieren (zb ein find() in einer Stringklasse)

Aber wie sieht es mit Funktionen aus, die generell nur mit einem bestimmten Typ Sinn machen?

Process process(...);
int bits = process.get_bitness();

oder

Process process(...);
int bits = get_bitness(process);

Was für Regel habt ihr da selbst für euch definiert?

Danke und Grüße,
Ethon

So viel wie möglich als freie Funktionen, solange dadurch die Kapselung erhalten bleibt.

Nun ja, das habe ich strikt so gemacht und meine process-Klasse wurde einfach nur ein Proxy für die Prozess-ID.
Einfach den Integer direkt umherreichen möchte ich allerdings auch nicht, das verbaut mir die Möglichkeiten, die ich mit einer Klasse habe. (zb mehr Daten hinzufügen)

man könnte es ja auch als statische funktion machen in der klasse

Wäre doch nur extra Schreibarbeit? Eine statische Funktion hat doch die selben Berechtigungen wie eine normale Memberfunktion, bis darauf dass ich this explizit übergeben müsste.

Ob dann als Memberfunktion oder als freie Funktion daneben find ich dann gar nicht mal so entscheidend, wobei schon allein weil die meisten IDEs das so schön anzeigen wohl doch die Memberfunktionsvariante vorziehen würde.

Das wäre auch ein Argument für mich.

Na, ich freue mich über weitere Anregungen.

So viel wie möglich als freie Funktionen, solange dadurch die Kapselung erhalten bleibt.

Sollte man diese freien Funktionen dannn static machen sofern man sie nicht noch irgendwo anders braucht?

314159265358979 schrieb:

So viel wie möglich als freie Funktionen, solange dadurch die Kapselung erhalten bleibt.

Sollte man diese freien Funktionen dannn static machen sofern man sie nicht noch irgendwo anders braucht?

Eine öffentliche API sollte wohl nie static sein, da man sie immer irgendwo anders braucht.
Es geht hier schließlich darum, ob man alle öffentliche Klassenfunktion immer wenn möglich frei implementieren soll.

Generell würde ich auch so viele Funktionen wie möglich frei machen, aber teilweise sind Memberfunktionen wegen Konsistenzgründen besser geeignet.

void Object::SetPosition(Vector2f position);
void         SetPosition(Object& this_, float x, float y); // ?

Nexus schrieb:

void Object::SetPosition(Vector2f position);
void         SetPosition(Object& this_, float x, float y); // ?

void Object::Transform(Transformation&);

bzw.

void Transformation::Transform(Object&);

Das ist aber auch nicht immer sinnvoll. An vielen Stellen ist es auch sinnvoll die Klasse die Operationen als Member selber implementieren zu lassen, anderswo passen freie Funktionen gut. Eine sinnvolle Aussage "immer so..." gibt es nicht. Ich finde Hauptsache konsistent. Ich glaub H. Sutter schrieb es am Beispiel von std::string. Ich mein mich zu erinnern, dass ich dieses Item im Gegensatz zum größten Teil des restlichen Inhalt der Bücher nicht so toll fand. Wenn ich mich richtig erinnere, kam er auf eine Schnittstelle von string mit vielleicht 1/3 Member und 2/3 freie Funktionen. Gerade für eine so viel benutzte Bibliotheksklasse fänd ich das extrem nervig immer überlegen zu müssen ob es nun eine member oder freie Funktion ist. Vor allem weil das Argument der besseren Kapselung im Fall einer Klasse der Standardbibliothek nicht wirklich zieht.