Es gibt ja verschiedene Leute, welche die Meinung vertreten, dass Funktionen, welche als nicht Memberfunktionen realisiert werden können, auch ausserhalb der Klasse realisiert werden sollten.

Ich frage mich gerade, wie weit sowas gehen sollte. Ich habe hier einen kleinen Code, welcher eine Rechteck-Klasse beschreibt. Ich bin gerade dabei, den Code zu überarbeiten und lagere momentan fast alle Funktionen aus. Es kommt mir auch irgendwie besser vor, aber dann hat mich doch plötzlich ein wenig der Zweifel gepackt. Ich schreib das mal schnell auf:

//////////////////////////////////////////////////////////////////////////
// Rect

class Rect
{
  // Attributes //
private:
  Coord m_topLeft; // Coord ist einfach ein Punkt (x,y).

  int m_width;
  int m_heigth;

  // Constructors & Destructor //
public:
  Rect(int x, int y, int width, int height);
  Rect(Coord const& topLeft, int width, int height);
  Rect(Coord const& topLeft, Coord const& bottomRight);
  Rect(Rect const& rect);

  ~Rect();

  // Operators //
public:
  Rect& operator =(Rect const& rect);
  bool operator ==(Rect const& rect) const;
  bool operator !=(Rect const& rect) const;

	// Methods //
public:
  Coord const& get_top_left() const;
  void set_top_left(Coord const& topLeft);

  int get_width() const;
  void set_width(int width);

  int get_height() const;
  void set_height(int height);
};

//////////////////////////////////////////////////////////////////////////
// Global Enums

enum Relation
{
  NONE,
  INTERSECTION,
  PARENT,
  CHILD
};

// Um die nachfolgenden Funktionen geht es.
// Diese Funktionen waren vorhin alles Methoden.
// Man kann sie aber genauso ausserhalb hinschreiben.

//////////////////////////////////////////////////////////////////////////
// Global functions

Coord calc_top_right(Rect const& rect);     // War früher get...
Coord calc_bottom_right(Rect const& rect);  // War früher get...
Coord calc_bottom_left(Rect const& rect);   // War früher get...

bool has_intersection(Rect const& first, Rect const& second);
Relation detect_relation(Rect const& first, Rect const& second);

bool is_element_of(Coord const& coord, Rect const& rect);

Ich bin gespannt auf eure Meinungen. Wo sollten diese Funktionen hin?

Grüssli

waere es uU sinnvoller in der Shape Klasse nur den Mittelpunkt zu speichern und anhand dessen die ecken bestimmen zu koennen?

weil aktuell ists doof: top_left ist member, aber top_right nicht und heisst auch komplett anders. das interface muss schon einheitlich sein...

wenn du topleft als punkt weiter speichern willst, dann mach noch eine freie calc_top_left funktion dazu, um das interface einheitlicher zu gestalten.

non member bringen dir hier einen enormen vorteil wenn du mal mehr klassen hast: calc_top_right() kann fuer alle Shapes funktionieren die ein get_width() anbieten - ohne dass du neuen code schreiben musst - einfach nur calc_top_right als template funktion.

Mach sie doch als statische Methoden. Wegen der Kapselung.

nein nein nein nein nein nein
das ist schlecht fuer die kapselung

Dann klär mich auf. Wieso?

Memberfunktionen mit get_..., wegen Einheitlichkeit und Lesbarkeit

bool has_intersection(Rect const& first, Rect const& second);

Kommt drauf an. Wenn du die has_intersection -Funktion noch für mehrere andere Formen überladen hast, würde ich sie draußen lassen. Wenn's die so erstmal nur für Rect gibt, würde ich sie mit reinnehmen.

Relation detect_relation(Rect const& first, Rect const& second);

Wie bei has_intersection .

bool is_element_of(Coord const& coord, Rect const& rect);

bool Rect::contains( Coord const& ) fände ich besser.

alles non member und operator== und co auch gleich non member.

Keine Ahnung, was der op== und != in der Klasse macht. Den habe ich normalerweise immer draussen. Ist auch bei Coord draussen. Also ka ^^

Shade Of Mine schrieb:

waere es uU sinnvoller in der Shape Klasse nur den Mittelpunkt zu speichern und anhand dessen die ecken bestimmen zu koennen?

Das wäre sicher sinnvoll, wenn ich mehrere verschiedene Shapes habe. Ich habe aber nur Rechtecke, bzw. eigentlich Regionen, welche aber immer rechteckig sind, und Punkte.

Aber mit weiteren Shapes, würde ich dir wahrscheinlich zustimmen.

Shade Of Mine schrieb:

non member bringen dir hier einen enormen vorteil wenn du mal mehr klassen hast: calc_top_right() kann fuer alle Shapes funktionieren die ein get_width() anbieten - ohne dass du neuen code schreiben musst - einfach nur calc_top_right als template funktion.

Naja, wenn ... derzeit aber definitiv nicht in Sicht. Allerdings, wer weiss was die Zukunft bringt

Ich bin gespannt auf weitere Meinungen.

Grüssli

Ich dachte immer, wenn eine Instanz benötigt wird, dann rein in die Klasse.
Wenn nicht, statisch und wenns noch andere Instanzen gebraucht werden, man also
nicht weiß, zu welcher Klasse es gehört, dann global oder besser Namespace.

\edit: Beim Vererben bringt das doch auch mehr Übersicht.

non member bringen dir hier einen enormen vorteil wenn du mal mehr klassen hast: calc_top_right() kann fuer alle Shapes funktionieren die ein get_width() anbieten - ohne dass du neuen code schreiben musst - einfach nur calc_top_right als template funktion.

Für welches Shape würde calc_bottom_right noch funktionieren und wirklich den bottom_right Punkt des Shapes und nicht der Boundingbox liefern?

Alles was ich ausserhalb der Klasse habe, kann ich wiederverwenden. Generell ist eine foo.bar() Syntax furchtbar restriktiv.

Wenn nun calc_top_right() non member ist, dann habe ich es automatisch fuer jedes Shape dass ein get_width() anbietet. ohne aufwand, einfach durch statische polymorphie.

Die gleiche funktionalitaet koennte man erreichen indem man alles Shapes von einer abstrakten Klasse Shape ableitet und dort calc_top_right() implementiert.

Aber ploetzlich sind wir von Shape abhaengig. Wenn ich jetzt ein calc_middle() will um den mittelpunkt zu bestimmen und der Designer von Shape hat daran nicht gedacht, dann pech gehabt.

Hier kommen eben non member ins Spiel. Ich kann jederzeit eine calc_middle() funktion implementieren die fuer alle Shapes funktioniert. Und Shapes sind alles was ein get_width() und get_height() anbietet. Ich brauche kleine laufzeit polymorphie.

Wir haben damit eine Moeglichkeit bestehende Klassen ohne vererbung zu erweitern. denn vererbung nur um funktionalitaet hinzuzufuegen ist boese.

Wenn wir das in der STL zb gemacht haetten, dann koennte ich
sort(container);
sagen um jeden beliebigen container zu sortieren.

Was dazu fuehrt, dass wir ploetzlich generischen Code viel einfacher schreiben koennen, weil man viel weniger spezialisieren muss.

Aber dieses

ohne aufwand, einfach durch statische polymorphie

versteh ich nicht.
Wie soll die Funktion auf einmal andere Formen aufnehmen, statt nur dem Rechteck.
Dafür muss man sie doch von einer Basisklasse ableiten oder?

Die gleiche funktionalitaet koennte man erreichen indem man alles Shapes von einer abstrakten Klasse Shape ableitet und dort calc_top_right() implementiert.

Und da dachte ich, das wäre das Standardkonzept, wie es in jedem Buch steht. So kann man sich irren. Aber man lernt ja nie aus.

\edit: ja durch Templates. Ist mir noch vorm Einschlafen eingefallen.

ohne aufwand, einfach durch statische polymorphie

versteh ich nicht.
Wie soll die Funktion auf einmal andere Formen aufnehmen, statt nur dem Rechteck.
Dafür muss man sie doch von einer Basisklasse ableiten oder?

Durch Templates:

template<typename ValueT>
Coord calc_top_right(ValueT const& value);

Grüssli

Nein, alles was geht raus aus der Klasse.
Siehe zB monoliths unstrung von Sutter, zB online: http://www.gotw.ca/gotw/084.htm oder in Effective C++ Style.
Oder auch Meyers: http://www.ddj.com/cpp/184401197

Grundsätzlich ist es mit klar, wieso man freie Funktionen Memberfunktionen vorziehen sollte.
Nun habe ich mir mal Deinen ersten Link angesehen, und dabei sind mir dann aber Zweifel gekommen.
Herb Sutter zieht da ja jede Menge Funktionen aus basic_string heraus und spricht an, dass die meisten der Funktionen sich auch auf andere STL-Container anwenden lassen würden.
Wenn ich mir aber jetzt sowas wie seine empty()-Templatefunktion ansehe:

template<class charT, class traits, class Allocator>
bool empty( const basic_string<charT, traits, Allocator>& s )
{
  return s.size() == 0;
}

dann ist dieses in der Form doch wieder nur für basic_string zu benutzen, oder?
Für die verschiedenen anderen Container müsste ich dann wieder andere Versionen anbieten. Wo ist also der Vorteil?

Ich würde das (vermutlich naiv) eher so machen:

template<typename T>
bool empty(const T& c)
{
    return c.size() == 0;
}

Grundsätzlich ist es mit klar, wieso man freie Funktionen Memberfunktionen vorziehen sollte.

Oftmals macht auch beides sinn ...
eine freie <template> Version die mit aehnlichen klassen auch funktioniert, und eine gebundene interne, die auf grund internas effizienter implementiert werden kann.

Ansonsten wuerd ich mich Shade Of Mine anschliessen. Vor allen den "interfaces" nen einheitliches Gesicht verpassen. Das dankt dir spaeter der, der den code warten muss. und schoen in mindestens nen namespace kapseln ...

Wenn man erst mal ne generische funktion hat, kann man spaeter bei der optimierung immer noch gebundene interne versionen bauen und auf die umsteigen, wenn das moeglich/ notwendig ist.

Ciao ...

lohnt es sich noch bier kalt zustellen und knabberkram zu kaufen?

lohnt es sich noch bier kalt zustellen und knabberkram zu kaufen?

1. Das ist grundsätzlich der erste Trollpost.
2. Nein, gibt keinen Grund, kannst also ruhig wieder gehen.

@Rest,
Bis jetzt eigentlich keine Antworten gegen dieses Vorgehen. Meine Zweifel haben sich verflüchtigt
Um die Klasse Rect gibt es übrigens einen namespace und somit auch um die Funktionen. Ich sollte vielleicht mal die Dokumentation umbennen von Global zu Free functions oder sowas ähnliches.

Jetzt habe ich womöglich noch ein anderes Designproblem. Aber dazu mache ich einen neuen Thread auf, sobald ich mich nochmals selber damit gründlich beschäftigt habe.

Danke!

Grüssli

Mir ist irgendwie nicht klar, wo der Vorteil ist, wenn die Funktionen frei sind, wenn sich eh nur basic_string mit ihnen benutzen lässt. Sind die Beispiele evtl. nur schlecht gewählt?

Wenn ich für alle Container die Funktionen wieder explizit überladen muss, kann ich sie doch eigentlich auch gleich wieder in die Klasse packen, oder?
Mir würde sich die Frage nicht stellen, wenn er (Sutter) generellere Funktionen aufgeführt hätte, wie ich sie oben im Beispiel genannte habe.

Trotzdem würde ich gerne meine Frage beantwortet haben. Auch wenn sie sich eher direkt auf die Ausführungen von Herb Sutter aus Shades Link bezieht.

Sutter geht in dem Link eben auf string ein.
Wenn man das ganze natuerlich fuer alle Container will, dann ist ein

template<typename ContainerT>
bool empty(ContainerT const& cont) {
  return cont.size()==0;
}

notwendig.

PS:
@sothis_:
Du koenntest hier ruhig mal etwas lernen und weniger trollposts machen. Wegen Leuten wie dir frage ich mich manchmal, warum ich das hier ueberhaupt mache. Kotzt mich an, echt.

Sutter geht in dem Link eben auf string ein.
Wenn man das ganze natuerlich fuer alle Container will, dann ist ein...

Wo ist denn der Sinn, freie Funktionen für etwas zu definieren, was man ohnehin nur für einen Spezialfall benutzen kann? Ist das Beispiel nur schlecht gewählt? Mir ist das irgendwie nicht so recht klar.

Und wenn ich mit 3 Methoden alles realisieren könnte, was mit dieser
Klasse machbar sein muss, dann können alle anderen freie Funktion werden, da
diese nur die 3 Methoden benötigen.

Laut Sutter gibts keine Performance-Einschränkungen und wenn mal was erweitert
werden müsste ist die ein leichteres, da man keine großartige
Klassenhierarchie verwenden muss.

@sothis_:
Du koenntest hier ruhig mal etwas lernen und weniger trollposts machen. Wegen Leuten wie dir frage ich mich manchmal, warum ich das hier ueberhaupt mache. Kotzt mich an, echt.

jetzt überreagiere doch nicht so. ist ja eine sehr angespannte stimmmung hier, dann geh ich halt wieder

SO weit ich das verstanden habe, geht es darum, die Kapselung soweit wie
möglich zu erhalten.

Und wenn ich mit 3 Methoden alles realisieren könnte, was mit dieser
Klasse machbar sein muss, dann können alle anderen freie Funktion werden, da[...]

Ja, das ist soweit schon klar, ich hänge mich allerdings (vielleicht zu sehr) an seinem Beispiel auf.
Das Interface der freien Funktionen ist ja nun direkt auf basic_string zugeschnitten. Da lässt sich (zumindest aus meiner sicht) nicht mehr allzu viel erweitern. Aber vielleicht verstehe ich auch nur was nicht richtig.

Shade Of Mine schrieb:

Sutter geht in dem Link eben auf string ein.
Wenn man das ganze natuerlich fuer alle Container will, dann ist ein...

Wo ist denn der Sinn, freie Funktionen für etwas zu definieren, was man ohnehin nur für einen Spezialfall benutzen kann? Ist das Beispiel nur schlecht gewählt? Mir ist das irgendwie nicht so recht klar.

Sutter hat sich dort nur gerade auf die Strings konzentriert, da er schaute, welche Funktionen man rausnehmen kann. Und wahrscheinlich um den Leser nicht zu sehr zu verwirren, hat er es derzeit bei dem basic_string gelassen.

Also ist das Beispiel vielleicht etwas schlecht gewählt, zufrieden? Wie kann man so ein Drama, um so etwas simples machen. Du solltest den Beruf Unternehmensberatung anstreben :p

@JustAnotherNoob,
Wenn ich dich richtig verstehe, fragst du, wieso eine Friendfunktion einer Membermethode bevorzugt werden sollte?
Ich zitiere mal direkt Sutter, aus dem ersten Text:

(There are some rare exceptions such as operations needing conversions on their left-hand arguments and some like operator<<() whose signatures don't allow the *this reference to be their first parameters; even these can normally be nonfriends implemented in terms of (possibly virtual) members, but sometimes doing that is merely an exercise in contortionism and they're best and naturally expressed as friends.)

Oder dann habe ich nicht verstanden was du meinst.

Grüssli