In einem meiner Übungsbücher gabe es eine Aufgabe in der man Factory-Funktionen erstellen sollte , mit einer abstrakten Überkalsse.
ich habe das ganze so gelöst :

class Shape {
    public:
       virtual void Draw() = 0;

       static Shape* Create(string type);
};

class Circle : public Shape {...};

class Square : public Shape {...};

Shape* Shape::Create(string type) {
    if ( type =...
}

int main()
{

   Shape* obj1 = Shape::Create("circle");

   obj1->Draw();

}

In der Lösung ist aber noch etwas anderes dabei: in den Klassen Circle und Square steht am ende noch

friend class Shape;

Warum ?Und welchen Vorteil bringt das ?

struct shape
{
    virtual void draw() const = 0;
    virtual ~shape() {}
};

struct circle : shape
{
    virtual void draw() const { std::cout << "circle::draw\n"; }
};

struct square : shape
{
    virtual void draw() const { std::cout << "square::draw\n"; }
};

struct shape_factory
{
    void add_creator(std::string const& what, std::function<shape*()> func) { creators.insert(std::make_pair(what, func));

    shape* create(std::string const& what) const
    {
        auto iter = creators.find(what);

        if(iter == creators.end())
            return 0;

        return iter->second();
    }

private:
    std::map<std::string, std::function<shape*()>> creators;
};

shape* create_circle() { return new circle; }
shape* create_square() { return new square; }

int main()
{
    shape_factory f;
    f.add_creator("circle", create_circle);
    f.add_creator("square", create_square);

    shape* s1 = f.create("circle");
    shape* s2 = f.create("square");

    s1->draw();
    s2->draw();
}

Ungetestet.

7xCore schrieb:

In der Lösung ist aber noch etwas anderes dabei: in den Klassen Circle und Square steht am ende noch

friend class Shape;

Warum? Und welchen Vorteil bringt das?

Ich vermute mal eher gar keinen. Es bedeutet,dass Shape Zugriff auf Interna von Square und Circle hat (Vielleicht um in Create einen privaten Ctor aufzurufen oder so ein Blödsinn). Wenig sinnvoll ist es, da eine Basisklasse keine Abhängigkeit zu ihren Kindklassen haben sollte. Das ist ziemlicher Unfug. Was hast Du denn da für ein Buch?

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.

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

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?

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.

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.

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.

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.