ich möchte jetzt ein Memento-Pattern einbauen. Normalerweise heißt es ja, dass das Memento selbst nicht für Erstellung/Wiederherstellung zuständig sein soll, sondern nur den State widerspiegelt. Hat das einen tieferen Sinn?

Ich hätte es jetzt so gebastelt:

class Object; // das soll gespeichert werden

class Mememento
{
public:
   Memento(const Object& obj); // das hier erstellt das Memento einfach

   void Restore(Object& obj); // das stellt das Objekt wieder her

private:
   // der State wird hier irgendwie abgebildet 
};

Nach den üblichen verdächtigen Quellen würde man hier eine Originator-Klasse drumbasteln (bzw. hier würde ich einfach freie Funktionen, evtl. mit namespace nutzen) und darin das Memento hauen, das dann aber einer einfachen Datenstruktur entspricht, die jetzt keine wirklichen Methoden hat (Setter/Getter, dann kann das aber auch einfach eine struct sein).

Das wäre also etwa so was:

namespace Originator
{
    struct Memento
    {
        // state
    }

    Memento createMemento(const Object& obj);
    void restoreFromMemento(Object& obj);
};

Frage 1: Ich sehe darin jedoch keinen Vorteil. Gibt es einen?

Frage 2:
Ich will eigentlich lieber:

Object Restore();

haben, aber Object ist non-copyable, jedoch moveable. Das sollte theoretisch ja reichen. Ein temporäres Objekt darf ich aber nicht moven, sodass

Object&& Restore();

nicht geht.

Bei

Object Restore();

bin ich aber darauf angewiesen, dass der NRVO korrekt anwendet, oder? Ist irgendwie doof sich darauf zu verlassen (oder ist das hier garantiert, weil es nicht mehr NRVO heißt?). Muss ich ansonsten zwangsläufig einen Umweg über ein Objekt wie:

class Restorer
{
public:
    Restorer(const& Memento memento); // erstellt temp
    Object&& Restore()&& {return std::move(temp);}

private:
    Object temp;
};

gehen, wobei in

Object obj = std::move(Restorer(memento)).Restore();

das temporäre Objekt ja die Anweisung überlebt, sodass das Verhalten wohldefiniert ist?

Beste Grüße,
Eisflamme

dass das Memento selbst nicht für Erstellung/Wiederherstellung zuständig sein soll

Dazu muesste es hoechstwahrscheinlich auf private Member zugreifen.

Originator-Klasse drumbasteln

Ist das Objekt dessen Zustand gespeichert werden soll.

Memento createMemento(const Object& obj);
    void restoreFromMemento(Object& obj);

Muss wahrscheilich auf private Daten von Object zufgreifen.

Warum willst du moven? Memento speichert den Zustand fuer spaeter, d.h. eine Weiterbenutzung des eigentlichen Objekts sollte nichts im Weg stehen. Wird es verschoben, kann es vielleicht nicht mehr so benutzt werden, wie ohne Verschiebung.

Wenn Originator == Object, dann kann Object einfach alles übernehmen, irgendwie hatte ich kurz den Gedanken, dass es doch toll wäre die Erstellung/Wiederherstellung aus Object herauszulösen... ohne mir jetzt erkennbare Vorteile.

Wenn ich aber eine freie Funktion habe, die Object zurückgibt, dann würde er ohne NRVO kopieren. Wenn Object nicht copyable ist, geht das aber nicht, also "müsste" ich das temporär erstellte Objekt moven, was natürlich nicht geht.

Wenn ich aber eine freie Funktion habe, die Object zurückgibt, dann würde er ohne NRVO kopieren. Wenn Object nicht copyable ist, geht das aber nicht, also "müsste" ich das temporär erstellte Objekt moven, was natürlich nicht geht.

Das sind doch alles nur Randueberlegungen. premature

Memento ist nur eine etwas eigene Form der Serialisierung. Hier wird eben keine datei oder aehnliches benutzt sondern ein Objekt.

Wenn ich es aber mit freier Funktion machen würde, warum wäre es dann premature? Du meinst, ich sollte einfach:

Object create(const Memento& m)
{
    Object obj(/* ... */);
    // tu was
    return obj;
}

schreiben und hoffen, dass der Compiler das schon von selbst moved?

Ist halt blöd, wenn mein Compiler das zufällig macht, ein anderer aber nicht, darum wollte ich das vorher diskutiert haben, um nicht compilerabhängigen Code zu schreiben.

schreiben und hoffen, dass der Compiler das schon von selbst moved?

Das ist erstmal NRVO. Und wenn du Object obj = std::move(create(...)) machst, dann sollte der move-Konstruktor aufgerufen werden.

Ich verstehe nicht, warum create/restore eine freie Funktion sein soll. Und da es hauptsaechlich um das zuruecksetzen in einen vorherigen Zustand geht, sollte die Klasse es explizit im Interface formulieren. Aehnlich wie bei Serialisierung, nur die Klasse Weiss, wie Objekte de-/serialisiert werden koennen.

Und wie gesagt, das mit der freien Funktion war falsch von mir gedacht, weil mein Gedankengang war: Man braucht Originator mit Originator != Object (das war falsch) und da ich Originator dann aber nicht als Klasse, sondern eher namespace sah, wurden die restore/create-Funktionen automatisch zu freien Funktionen.

War Käse, werden jetzt Methoden von Object, wie Du ja vorgeschlagen hast.

Und wenn du Object obj = std::move(create(...)) machst, dann sollte der move-Konstruktor aufgerufen werden.

Da braucht es kein move . Solange create(...) ein rvalue ist (was bei obiger Definition der Fall ist), dann wird automatisch der Move-Konstruktor gewählt.

Für jetzt reicht zwar mein einfaches System (auch wenn es durch Kopien langsam für riesige Datenmengen ist, die zum Glück aber eh nicht praktikabel sind), aber besser ist immer gut.

Auf die (sehr) Schnelle hat mein googlen nichts ergeben. Hast Du rasch einen Link oder das richtige Stichwort parat? Falls das in eine Suche Deinerseits ausarten würde, mache ich das natürlich selbst.

Und wenn es um Baumstrukturen geht, sind http://en.wikipedia.org/wiki/Persistent_data_structure ganz gut.

http://isocpp.org/blog/2012/12/value-semantics-and-concepts-based-polymorphism-sean-parent

Leider ist die Qualität des Videos nicht so dolle.

In seinen neueren Going Native 2013 Talks gibt es Parallelen, die haben aber weniger was mit Undo/Redo zu tun.

Auf alle Fälle interessante Ideen drin.

Leider sind meine Baumstrukturen relativ komplex, sodass es eigentlich Sinn ergeben würde, dass ich nur die Änderungen speichere. Aber es reicht von der Performance gerade noch aus.

knivil:
Danke auch dafür, da schaue ich dann als nächstes rein.