Frage zu factory-function

314159265358979

Das weiß ich nicht. Poste doch mal die Lösung.
Klingt aber auf jeden Fall schwachsinnig.

7xCore

Also dieses friend macht nur klar das die basis klasse zugriff auf die unterklassen hat ?

brotbernd

7xCore schrieb:

Also dieses friend macht nur klar das die basis klasse zugriff auf die unterklassen hat ?

Eine friend Klasse hat Zugriff auf protected und private Elemente der Klasse. Das ist generell selten sinnvoll und besonders schwachsinnig, wenn die Basisklasse auf ihre Spezialisierungen zugreift.

freaky

Ja, wobei es meiner Meinung nach mehr Sinn machen würde, in der Basisklasse protected Member oder Methoden bereit zu stellen, die dann benutzt werden. Das die Basisklasse in Unterklassen zum friend wird, habe ich noch nicht gesehen.

7xCore

Ok das hat meine Frage eigentlich beantwortet.Danke für eure Hilfe.
Eine kleine Frage dann noch: wann würde man dann friend benutzen ?

freaky

Zum Beispiel um den << Operator in der Klasse zu überladen, um solche Sachen zu ermöglichen:

#include <iostream>

class foobar
{
    public:
         int test;
         foobar(int number) : test(number) { }
         friend std::ostream& operator<<(std::ostream& out, const foobar& fb)
         {
             out << fb.test;
             return out;
         }
};

int main()
{
    foobar fb(5);
    std::cout << fb;
}

Ist jetzt nur ein kleines minimal Beispiel davon. friend bei Klassen zu benutzen, ist meiner Meinung nach schlechter Stil, weil die Kapselung und sonstiges flöten geht. Ich habe es aufjedenfall bisher noch nicht gebraucht.

hustbaer

brotbernd schrieb:

Eine friend Klasse hat Zugriff auf protected und private Elemente der Klasse. Das ist generell selten sinnvoll

Ach?

und besonders schwachsinnig, wenn die Basisklasse auf ihre Spezialisierungen zugreift.

Wirklich?

theta

Wenn die Konstruktoren in Circle und Square privat sind, könnte man mit dem friend auch bezwecken, dass nur Shape die beiden erzeugen kann und zwar so wie das eben die Factory Funktion in Shape vorschreibt (z.B. nur mit new, mit anschliessendem Initialize(..) etc.).

brotbernd

hustbaer schrieb:

brotbernd schrieb:

Eine friend Klasse hat Zugriff auf protected und private Elemente der Klasse. Das ist generell selten sinnvoll

Ach?

und besonders schwachsinnig, wenn die Basisklasse auf ihre Spezialisierungen zugreift.

Wirklich?

Soll ich mich jetzt selber korrigieren? Wie wär es mit einer sinnvollen Aussage. Ich habe kein Problem damit, wenn mich jemand eines Besseren belehrt, also einfach raus damit.

7xCore

hustbaer schrieb:

brotbernd schrieb:

Eine friend Klasse hat Zugriff auf protected und private Elemente der Klasse. Das ist generell selten sinnvoll

Ach?

und besonders schwachsinnig, wenn die Basisklasse auf ihre Spezialisierungen zugreift.

Wirklich?

Solche Kommentare sind wircklich unnötig.Tut mir leid wenn ich nicht so schlau wie du bin, aber es hat mir echt geholfen, wie es brotbernd erklärt hat.

hustbaer

Naja, Hinweise darauf dass etwas selten sinnvoll bzw. "besonders schwachsinnig" ist, ohne Begründung, sind für mich auch nicht wirklich hilfreich.

z.T. friend , und wozu es gut ist, steht hier einiges:
http://www.parashift.com/c++-faq-lite/friends.html

Beispiele wo man oft sinnvoll friend verwenden kann wären z.B. Operatoren (siehe FreakY<3Cpp's Beispiel).

Was das spezielle Thema "Basisklasse greift auf Spezialisierungen zu" angeht: ich hab' in einem meiner Projekte in der Arbeit z.B. genau so einen Fall.

Es gibt eine Basisklasse GUI::Control . Aus bestimmten Gründen müssen diese GUI Controls nach einem bestimmten Schema 2-Phase konstruiert werden. Also gibt es ein Funktionstemplate GUI::Control::CreateControl<T> , wo der nötige Code drinnen steht.
Um Unfälle zu vermeiden machen die abgeleiteten Control-Klassen ihren Ctor private (bzw. protected, wenn sie selbst sinnvoll als Basisklasse verwendet werden können), und erklären GUI::Control zum friend .

Ich finde das nicht besonders schwachsinnig, sondern eigentlich ganz gut so.

Was in vielen Fällen wirklich schwachsinnig wäre, ist, wenn die Basisklasse die abgeleiteten Klassen "kennt". Wobei ich mir fast sicher bin, dass es auch da ein paar Fälle gibt, wo es sinnvoll sein kann so ein Konstrukt zu haben.

brotbernd

Warum erzeugt denn die Basisklasse Instanzen? Wieso macht das nicht etwas wie GUI::ControlFactory::CreateControl<T> , das dann friend ist.
Die Schwachsinnigkeit bezog sich natürlich auf Fälle, bei denen die Basisklasse die Spezialisierungen 'kennt'. Andere Konstrukte sind mir gar nicht in den Sinn gekommen. Kommen sie mir ehrlich gesagt auch immer noch nicht. Aber vielleicht gibt es sie ja und ich änder meine Aussage von schwachsinnig zu 'eher ungewöhnlich und i.d.R. nicht empfehlenswert'.

hustbaer

brotbernd schrieb:

Warum erzeugt denn die Basisklasse Instanzen? Wieso macht das nicht etwas wie GUI::ControlFactory::CreateControl<T> , das dann friend ist.

Weil ich es für fragwürdig halten würde, eine "Control Factory" einzuführen.
Die Control Klasse weiss immer noch am besten wie "ihre" Instanzen zu erzeugen sind. Und der einzige Grund, eine "Control Factory" zu haben, wäre die "CreateControl" Funktion zu hosten.

Ja, man könnte es auch so machen. Ich hab' mir das auch schon überlegt. Aber es macht für mich einfach keinen Sinn, daher lasse ich es so wie es ist.

Aber vielleicht gibt es sie ja und ich änder meine Aussage von schwachsinnig zu 'eher ungewöhnlich und i.d.R. nicht empfehlenswert'.

Muss schön sein sich so sicher zu sein.
Tu was du willst.