Design Frage -> Member- oder nicht Memberfunktion

[RHBaum]

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 ...

[sothis_]

poasting in a design discussion thread.

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

[Dravere]

sothis_ schrieb:

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

[Tachyon]

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.

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.

[Shade Of Mine]

Tachyon schrieb:

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.

[Tachyon]

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.

[Chuck]

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
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_]

Shade Of Mine schrieb:

@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

[Tachyon]

Chuck schrieb:

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.

[JustAnotherNoob]

was sich mir als Frage zum zweiten Text stellt:
Was haben friend Funktionen für einen Vorteil gegenüber Membern?(Ich ziele da auf den Algorithmus zu Beginn des Textes ab)
Ich habe das Argument mit der Kapselung verstanden und auch dass das Interface dadurch teilbarer wird, aber ist eine Friendfunktion nicht auch in einem gewissen Maße irreführend?

[Dravere]

Tachyon schrieb:

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

[hmmm???]

Und was ist mit Information hiding? Warum weiß eine globale Funktion wie man an die Eckpunkte eines Rechtecks kommt? Sowas weiß das Rechteck und sonst keiner. Was würde den passieren, wenn man das Rechteck auch drehen können will und es dann nicht mehr parallel zu den Achsen liegt? Dann würde die globale Funktion was falsches berechnen und müsste geändert werden. Das hätte zu Folge das sie für andere Shapes nicht mehr funktioniert. Welche anderen Shapes diese Funktionen überhaupt noch nutzen könnten hat sowieso noch keiner gesagt.

[@camper]

campers meing dazu würde mich interessieren.

[Nexus]

Und was wäre mit globalen Funktionen (z.B. als Template), die auf die jeweiligen Methoden zugreifen? Dann könnte alles intern geregelt werden und eine gemeinsame Schnittstelle wäre dennoch vorhanden...

[Shade Of Mine]

hmmm??? schrieb:

Und was ist mit Information hiding? Warum weiß eine globale Funktion wie man an die Eckpunkte eines Rechtecks kommt? Sowas weiß das Rechteck und sonst keiner. Was würde den passieren, wenn man das Rechteck auch drehen können will und es dann nicht mehr parallel zu den Achsen liegt? Dann würde die globale Funktion was falsches berechnen und müsste geändert werden. Das hätte zu Folge das sie für andere Shapes nicht mehr funktioniert. Welche anderen Shapes diese Funktionen überhaupt noch nutzen könnten hat sowieso noch keiner gesagt.

Ja, die Eckpunkte sind schlecht gewaehlt als Beispiel.
Aber das ist immer so, es geht um ein Prinzip aber anstatt nachzudenken wird sich an Beispielen aufgehaengt.

Sehen wir uns dagegen std::string an, dann ist es einfach 20-30 Beispiele zu bringen was als non member deutlich besser waere. Hier bei dem Rechteck Beispiel geht es deshalb nicht gut, weil es ein minimalistisches Beispiel ist dass hier im Thread nichtmal fertig implementiert ist.

Ist das echt so schwer zu verstehen? Muss man alles klein bis ins hinterletzte Details durchdesignen bevor ihr das Konzept versteht?

OK. Machen wir das halt:

nehmen wir std::string und die member funktion assign().
Kann ich perfekt als

template<typename ContainerT, typename Iter>
void assign(ContainerT& cont, Iter first, Iter last) {
  cont.clear();
  while(first!=last) {
    cont.push_back(*first);
    ++first;
  }
}

implementieren.

Der Vorteil:
ich habe jetzt automatisch ein range insert fuer _alles_ dass ein push_back und ein clear anbietet.

Man kann die komplette Schnittstelle aller container dadurch enorm verbessern. Die STL hat den ersten Schritt gemacht und iteratoren als Konzept genommen um algorithmen von datenstrukturen zu abstrahieren. aber viele algorithmen sind in den containern drinnen. man schreibt dauernd den selben code. 20 mal assign, 17 mal op=, 25 vergleichsoperatoren, etc. alles ist trivialst als non member loesbar. Man braucht fast keine member funktionen um eine klasse funktionsfaehig zu machen.

und selbst wo man member bzw. friends braucht, ist eine non member funktion trotzdem genial, auch wenn sie nur forwarded - weil es eben die kapselung soviel verbessert.

generell sind member funktionen furchtbar. sie sind ein notwendiges uebel, aber non member sind einfach soviel besser.

[hmmm???]

Shade Of Mine schrieb:

hmmm??? schrieb:

Und was ist mit Information hiding? Warum weiß eine globale Funktion wie man an die Eckpunkte eines Rechtecks kommt? Sowas weiß das Rechteck und sonst keiner. Was würde den passieren, wenn man das Rechteck auch drehen können will und es dann nicht mehr parallel zu den Achsen liegt? Dann würde die globale Funktion was falsches berechnen und müsste geändert werden. Das hätte zu Folge das sie für andere Shapes nicht mehr funktioniert. Welche anderen Shapes diese Funktionen überhaupt noch nutzen könnten hat sowieso noch keiner gesagt.

Ja, die Eckpunkte sind schlecht gewaehlt als Beispiel.
Aber das ist immer so, es geht um ein Prinzip aber anstatt nachzudenken wird sich an Beispielen aufgehaengt.

Sehen wir uns dagegen std::string an, dann ist es einfach 20-30 Beispiele zu bringen was als non member deutlich besser waere. Hier bei dem Rechteck Beispiel geht es deshalb nicht gut, weil es ein minimalistisches Beispiel ist dass hier im Thread nichtmal fertig implementiert ist.

Ist das echt so schwer zu verstehen? Muss man alles klein bis ins hinterletzte Details durchdesignen bevor ihr das Konzept versteht?

OK. Machen wir das halt:
...

Jetzt versuch mal nicht mich hier als blöd hinzustellen. Es gibt hier durchaus einige Leute die das Prinzip verstanden haben. Nur weil ein paar es nicht kannten und Zwischenfragen gestellt haben ist das noch lange nicht das neue Thema. Das Prinzip mag ja bei Containerklassen und ähnlichem funktionieren, aber deswegen muss man noch lange nicht wie ein Programmierroboter nach Meyers Algorithmus Methoden auslagern. Man sollte vorher schon noch etwas nachdenken. Bei den meisten Klassen enthalten die Methoden noch viel spezielleres Wissen über die Klasse, als bei einem Rechteck und da ist es noch weniger sinnvoll das alles auszulagern.

Wenn du immer noch der Meinung bist, dass die getter für die Eckpunkte aus Draveres Rect Klasse raus sollen, dann antworte ernsthaft auf meine Fragen und nicht auf was ganz anderes.

[GespürFürCode]

Dravere schrieb:

aber dann hat mich doch plötzlich ein wenig der Zweifel gepackt...

Ja, manche Leute merken es, wenn sie hässlichen Code schreiben. Und einen Koordinaten-Getter als Member und die 3 anderen als freie Funktionen zu implementieren ist wirklich hässlich.

[alter hase]

Wenn ich auf der Arbeit mit so einem Codedesign ankäme, würden die mich einen durchgeknallten Irren nennen und mich wieder nach Hause schicken.
Seid ihr alle nur Hobbyprogrammierer, die alleine in ihrem Kämmerlein aus Spaß an der Sache programmieren? Habt ihr schonmal in einem Team mit mehr als 5 Leuten gearbeitet, wo alle unterschiedlich viel über C++ wissen?

Bei solchen Diskussionen beschleicht mich oft das Gefühl, dass die propagierten Modelle und Vorgehensweisen rein akademischer Natur sind und sich in der harten Praxis (noch lange) nicht durchgesetzt haben. Oder um es mal weniger freundlich auszudrücken: man sollte sich vielleicht nicht immer von dem Geschwätz von ein paar Schnöseln beeindrucken lassen, die zwar viele Bücher gelesen haben und arrogant daherreden können, aber bei denen es fraglich ist, ob sie ihre Ansichten und Modelle schon mal in der Praxis erprobt haben.

Ich schreibe lieber Code, der einfach zu verstehen ist und wo ich sicher bin, dass die restlichen Teammitglieder ihn auch adaptieren können. Das ist effizienter als akademische Überlegungen in vordergründig tollen Code umzusetzen, dessen Intention am Ende nicht offensichtlich ist und der deshalb ignoriert wird.

[Shade Of Mine]

alter hase schrieb:

Ich schreibe lieber Code, der einfach zu verstehen ist und wo ich sicher bin, dass die restlichen Teammitglieder ihn auch adaptieren können.

Das ist der pragmatische Ansatz. Keine Frage, es funktioniert.
Das ist halt die Frage die es immer und ueberall gibt:
weiterbildung ja oder nein

Man hat deutliche Vorteile von Weiterbildung, aber es ist eben ein Aufwand. Viele Leute fuerchten Aufwand natuerlich denn Aufwand kann bedeuten dass wir mehr Resourcen hineinstecken als wir dann hinaus bekommen.

Andererseits wenn sich nie jemand weiter entwickelt, wuerden wir immer noch in hoehlen leben.

Kleine teams sind natuerlich flexibler was Weiterbildung betrifft - deshalb sind die besten Teams idR relativ klein.

das trifft nicht nur auf programmierung zu sondern auf so ziemlich alle bereiche.

das einzige was man machen kann ist der nachkommenden generation bereits diese weiterbildung als standard bildung beizubringen. so funktioniert die welt.