da ich keine Lust habe operator= und copy-ctor zu schreiben, fand ich Folgendes:

class CopyableClass
{
public:
    CopyableClass(CopyableClass& other); // wie auch immer implementiert
    // swap gebe es auch!
    CopyableClass& operator=(CopyAbleClass other)
    {
        this->swap(*this, other);
    }
};

Jetzt habe ich aber kein swap. Wenn CopyableClass moveable ist, hätte ich gedacht, dass Folgenes geht:

class CopyableAndMoveableClass
{
public:
    CopyableClass(CopyableClass& other); // wie auch immer implementiert
    // swap gibt's nicht, aber move-ctor + move-assignment-operator
    CopyableClass& operator=(CopyAbleClass other)
    {
        *this = std::move(other);
    }
};

Aber der sagt, operator= sei dort mehrdeutig. Klingt auch erstmal einleuchtend.

Also:

class CopyableAndMoveableClass
{
public:
    CopyableAndMoveableClass(CopyableClass& other); // wie auch immer implementiert
    // swap gibt's nicht, aber move-ctor + move-assignment-operator
    CopyableAndMoveableClass& operator=(const CopyAbleClass& other)
    {
        *this = std::move(CopyableAndMoveableClass(std::move(other)));
    }
};

Das Doppel-Move ist doch korrekt, oder? Der muss schließlich move-ctor und move-assignment-Operator nutzen, also brauchen wir hier zwei rvalue-Referenzen, somit darf das Ding nicht benannt sein, also zwei Mal move.

Jetzt habe ich mich aber recht weit verstrickt und frage Mal nach, ob daran etwas faul ist oder es eine bessere Lösung gibt. Mein copy-ctor macht eine deep copy. Ich könnte natürlich auch den Doppelcode in eine Funktion ausgliedern und von copy-ctor/copy-assignment-op aufrufen lassen, würdet ihr das eher empfehlen?

Nachteil ist natürlich, dass wir hier die Schreibarbeit mit zwei zusätzlichen Moves bezahlen. Aber die dürften doch eigentlich leicht wegzuoptimieren sein. Wir moven etwas in eine temporäre Variable und von dieser weiter. Also kann der doch wohl schlauerweise auch direkt von der Kopie moven. Ein move bleibt natürlich nicht aus, schießlich wollte ich unbedingt den copy-ctor nutzen.

Was denkt ihr?

Dankesehr

Ist es das, was du willst?

Edit: Gut, swap zu implementieren ist nicht sonderlich schwierig. Trotzdem würde ich zum besseren Verständnis gerne meine Variante diskutieren.

Das Doppel-Move ist doch korrekt, oder? Der muss schließlich move-ctor und move-assignment-Operator nutzen, also brauchen wir hier zwei rvalue-Referenzen, somit darf das Ding nicht benannt sein, also zwei Mal move.

Die Moves sehen mir beide falsch aus. Das innere tut gar nichts, da das Objekt nicht movebar ist. Das Aussere ist unnoetig, da temporaere Objekte direkt gemoved werden koennen.

Eisflamme schrieb:

Theoretisch schon, aber ich habe kein swap, daher suche ich eine Lösung, die sich der moveability bereichert. Wie gesagt hat meine Variante jedoch Overhead. Ist der denn größer als beim copy-swap-Idiom?

Implementier doch einfach swap, sehe das Problem nicht.

Kellerautomat:
Wieso ist das innere Objekt denn nicht movebar? Und das äußere brauche ich deswegen, weil mein MSVC sonst eine Doppeldeutigkeit meldet. Das direkte Moven ohne Angabe ist doch wohl eine Optimierung, oder nicht?

Wieso ist das innere Objekt denn nicht movebar?

Weil es const ist.

Eisflamme schrieb:

Und das äußere brauche ich deswegen, weil mein MSVC sonst eine Doppeldeutigkeit meldet. Das direkte Moven ohne Angabe ist doch wohl eine Optimierung, oder nicht?

Glaube ich dir nicht. Es ist eine Temporary und damit ein RValue. Keine Optimierung.

Das mit const stimmt natürlich, albern. Aber ohne const& habe ich die Doppeldeutigkeit. Also geht das so wohl nicht.

Also wenn ich nicht die Parent- und Neighborzeiger der struct-Instanz (bzw. eines Datenmembers davon) ändern müsste, dann wäre swap schnell gemacht. Genau so wie copy-ctor.

Aber Moment, beim swap muss ich doch wieder alles schreiben, was ich auch im copy-ctor mache, also löse ich damit mein Problem (keine Lust deep copy zwei Mal zu schreiben) doch eigentlich gar nicht.

Ein Trugschluss. Da ist kein Duplikation drin. swap macht schließlich auch etwas mit dem alten Inhalt.

[...]

Dann klinke ich mich hier mal aus. Das ist mir zu schwammig.

class Node
{
public:
    typedef std::unique_ptr<Node> NodePtr;
    typedef std::vector<NodePtr> NodePtrs;
    typedef std::vector<const Node*> ConstNodePtrs;
    // ...

private:
    NodePtrs children;
    ConstNodePtr parent; // natürlich ohne Besitz, ist jetzt korrigiert
    ConstNodePtrs specialNeighbors;
};

Das Ding soll moveable und copyable sein, wie löst man das sauber? Habe gerade Mal ins std::set reingeschaut, aber das ist mir mit den ganzen Basisklassen, Proxyobjekten und Allokatoren gerade etwas unübersichtlich geworden.

Hm, da fällt mir auf, dass mein Problem doch nicht gelöst ist. Wenn ich move oder swappe, muss der parent-Ptr ja doch wieder angepasst werden. Dafür auch nur der, aber diese Anpassung habe ich trotzdem wieder doppelt (wie gesagt in OP, auslagerbar ist die).

Gut, dann wäre meine aktuelle Lösung so was:

Node::Node(const Node&& other) : parent(std::move(other.parent)), children(std::move(other.children)), specialNeighbors(std::move(other.specialNeighbors))
{
    // foreach children: parent = this setzen
}

Node& Node::operator=(Node&& other) 
{
    parent = std::move(other.parent);
    children = std::move(other.children);
    specialNeighbors = std::move(other.specialNeighbors);

    // foreach children: parent = this setzen
}

Node::Node(const Node& other) : parent(other.parent), children(other.children), specialNeighbors(other.specialNeighbors)
{
    // deep copy, das ist einiger Aufwand
}

void Node::swap(Node& other)
{
    std::swap(parent, other.parent);
    std::swap(children, other.children);
    std::swap(specialNeighbors, other.specialNeighbors);

    // wieder Anpassung des Parent von children
}

Node& Node::operator=(const Node& other)
{
    swap(other); // gut, hier Mal verkürzt
    return *this;
}

Ungetestet, weil hier im Forum getippt. Habt ihr Verbesserungsvorschläge?

T& operator = (const T&); // Copy Assignment
T& operator = (T&&); // Move Assignment

Hm, wie konnte man solche Überladungen noch mal zusammen legen? Ah, genau!

T& operator = (T); // Copy Assignment + Move Assignment

Für den Standard ist das allerdings nur ein copy assignment operator, was etwas lustig ist. Praktisch gesehen sollte das aber eigentlich keinen Unterschied machen.

Dann zu deinem Problem: Müssen die Nodes wirklich ihren Parent kennen? Ich frage weil ich diese Struktur schon oft an Stellen gesehen habe, an denen das nicht nötig war, und einfach nur alles verkompliziert hat.

Bzgl. Parent- und Neighbor-Kenntnis. Ich kann das jetzt nur wieder anhand einem hoffentlich geeigneten Parallelbeispiel ausdrücken. Ein Node ist bei mir so etwas wie eine Menge und ein Child ist eine Untermenge. Die Untermengen sind disjunkt. Grundsätzlich kann aber die Menge einfach alle - sagen wir Mal - natürichen Zahlen enthalten.

Dann könnte man es weiter beschreiben mit: node->SetzeZahl(10); und das soll nur funktionieren, wenn:
- 10 nicht in der Obermenge (Parent) ist
- 10 nicht bereits in einer disjunkten Menge (SpecialNeighbors) ist

Besitz ist natürlich nur von den children. Hab's oben korrigiert.

Also mit dem Beispiel der Mengen, ich will ja einfach schreiben:

Menge menge;
menge.setzeZahl(10);
menge.setzeZahl(20);

Menge& untermenge = menge.erzeugeKind();
untermenge.setzeZahl(15); // führt zu nichts
untermenge.setzeZahl(10); // gut

So finde ich das von der Bedienung her intuitiv. Oder sollte ich das nicht wollen? Wie würdest Du das denn dann umsetzen?

Wie würdest Du das denn dann umsetzen?

Was denn genau? Entweder bin ich blind, oder du hast immer noch nicht verraten, was das werden soll...

Also es handelt sich um einen Mengenbaum und die Kind-Elemente sind Untermengen. Die Untermengen mit gleichem Parent sind wie gesagt disjunkt. Wenn der Benutzer etwas einfügen möchte, soll die Methode daher prüfen:

1. ob die Zahl bereits in einer anderen Menge auf derselben Ebene drin ist
2. ob die Zahl auch in der Obermenge drin ist, sonst lässt sie sich nicht einfügen

Edit: Vielleicht sollte man noch dazu sagen, dass diese Mengen über ein UI befüllt werden sollen. Im UI kann man quasi in einer großen Matrix die Zahlen anklicken. Wenn die Zahl nicht in der Obermenge ist, wird die Zahl aber ausgegraut und ein Klick über Menge.setzeZahl(10); führt eben zu nichts. Man kann sich aussuchen, welche Menge man gerade befüllen möchte.

Gerne liefere ich mehr Details, dafür müsste ich aber auch wissen, was noch als wichtig erachtet wird.

Edit: Ich meine, im Prinzip würde ich nur gerne, wenn ich lese "Node copy/moveability ergibt keinen Sinn" hören, wie es denn Sinn ergäbe. Du meintest ja "Tree drüberhauen", dann habe ich gesagt, wieso ich das unschön finde. Und jetzt würde ich wiederum gerne hören, dass meine Argumente in aller Regel für die Tonne sind (und wieso) oder dass das durchaus Sinn ergibt. Dass ich nicht nach einer supertollen Komplettlösung fragen kann, wenn ich die ganzen Detailinfos nicht biete, ist mir klar. Ihr sollt mir da ja auch keine Arbeit abnehmen. Keine Ahnung, ob meine Antwort-Wünsche jetzt total unangemessen sind...

Kopieren ist allerdings etwas anderes, denn das geht auch mit Teilbäumen. Ist halt die Frage, ob man das überhaupt braucht.