friend bool operator < (const A& Aobj1, const A& Aobj2)

Wieso ist hier eine Überladung per globaler freiend Funktion nötig?

Danke

ich habe mir gerade die Frage gestellt, wo der Unterschied zwischen Kopierkonstruktor und Zuweisungsoperator besteht.

Der Kopierkonstruktor erzeugt ein neues Objekt, indem ein bereits existierendes kopiert wird. Der Zuweisungsoperator überschreibt ein bestehendes Objekt.

OOP Anäfnger schrieb:

friend bool operator < (const A& Aobj1, const A& Aobj2)

Wieso ist hier eine Überladung per globaler freiend Funktion nötig?

Wer sagt, dass diese nötig ist? Ohne Kontext kann man dazu nichts sagen.

friend bool operator < (const A& Aobj1, const  A& Aobj2){
   if(Aobj1.ival<Aobj2.ival)
      return true;
   else return false;
}

Die Frage ist: Brauchst du überhaupt Zugriff auf private Membervariablen? Denn wenn ein Getter sowieso angebracht ist, warum nicht diesen nutzen?

Aber wieso get, wenn ich die Überladung als Klassenmethode mache?

Du machst die Operatorüberladung nicht als Klassenmethode.

Macht man die Überladung nicht in den Public Bereich der Klasse?

Nein, du machst sie global (hier für den Fall des operator< , je nach Operator siehts ein wenig anders aus). Aber lies doch den Artikel, dort wird das alles erklärt!

Macht man die Überladung nicht in den Public Bereich der Klasse?

Steht in dem Artikel.

Trägt unter anderem zur Symmetrie des Operators bei.

Also gilt das nur bei den Vergleichsoperatoren, dass man diese als globale Funktion überladen sollte.

Nein -> Artikel lesen!

Allerdings ist das nicht nötig, wenn die Klasse A sauber gekapselt ist und Get-Methoden für ival anbietet. Ich rate dir zu diesem Schritt.

Ich rate nicht zu diesem Schritt, wenn durch die get/set-Methoden kein Mehrwert ausserhalb der Klasse erreicht wird. Mittels friend oeffne ich explizit fuer diese Funktion den private-Bereich. Mittels get/set oeffne ich fuer alle anderen den private-Bereich.

Allerdings ist das nicht nötig, wenn die Klasse A sauber gekapselt ist und Get-Methoden für ival anbietet. Ich rate dir zu diesem Schritt.

Ich rate nicht zu diesem Schritt, wenn durch die get/set-Methoden kein Mehrwert ausserhalb der Klasse erreicht wird. Mittels friend oeffne ich explizit fuer diese Funktion den private-Bereich. Mittels get/set oeffne ich fuer alle anderen den private-Bereich.

Ähnliche Diskussion zu einem anderen Operator siehe auch hier - ich würde hier wie auch im op<< - Fall weder zur friend-deklaration noch zu allgemeingültigen Gettern raten, sondern eine Methode anbieten die die eigentliche Arbeit des op< übernimmt:

class C : public boost::less_than_comparable<C>
{
  public:
  bool lessThan(C const& other) const
  {
    /* Zugriff auf private Daten */
  }
};

inline bool operator < (C const& lhs, C const& rhs)
{
  return lhs.lessThan(rhs);
}

Ich rate nicht zu diesem Schritt, wenn durch die get/set-Methoden kein Mehrwert ausserhalb der Klasse erreicht wird.

In vielen Fällen entsteht ein Mehrwert, weil eine öffentliche Eigenschaft verglichen wird, also sowieso entsprechende Get- und Set-Methoden notwendig sind. Aber der Einwand ist natürlich berechtigt.

pumuckl schrieb:

ich würde hier wie auch im op<< - Fall weder zur friend-deklaration noch zu allgemeingültigen Gettern raten, sondern eine Methode anbieten die die eigentliche Arbeit des op< übernimmt:

class C : public boost::less_than_comparable<C>
{
  public:
  bool lessThan(C const& other) const
  {
    /* Zugriff auf private Daten */
  }
};

Nun ja, man kanns auch übertreiben. Wenn du dieses Konzept konsequent durchziehst, landest du bei Java-Konstrukten wie a.equals(b) oder a.compareTo(b) . Und zwar zusätzlich zu den freien Funktionen – das ist ja das Schlimme. In Java ist sind solche Methoden okay, weil es keine freien Funktionen oder Operatoren gibt. Aber in C++? Welchen Mehrwert bringt lessThan() ? Man muss mehr Code schreiben, hat eine asymmetrische Methode mit zusätzlicher Indirektion und bietet zwei Funktionen für den genau gleichen Zweck an. Rechtfertigt das Vermeiden von friend wirklich diese Nachteile?

Wie schon im verlinkten Thread angedeutet: Man kann mit dem Versuch, die Kapselung zu erhöhen, das genaue Gegenteil erreichen. Zumindest wenn man Kapselung nicht nur durch formale Aspekte wie "ist Memberfunktion der Klasse" definiert, sondern durch semantische ("hat Zugriff auf private Member"). Den Ansatz, Schnittstellen nicht unnötig aufzublähen, sehe ich nämlich als wichtigen Bestandteil dieses Konzepts an.

Nur, damit ich nicht missverstanden werde: Ich finde es durchaus gut, wenn eine Klasse weitgehend für sich selbst zuständig ist, und will friend keinesfalls verharmlosen. Es ist ein Sprachmittel, das mit Bedacht eingesetzt und wenn sinnvoll möglich vermieden werden soll. In vielen Fällen (z.B. operator+= und operator+ ) geht das auch sehr elegant. Aber meiner Meinung nach ist eine kategorische Abneigung gegen Sprachmittel wie friend nicht unbedingt förderlich, wenn es ums Design einer Klassenschnittstelle geht. Denn erst durch die Kombination der verschiedenen Möglichkeiten kommt das volle Potenzial einer Programmiersprache zur Geltung.