3. operator= über copy-ctor implementieren?

operator= über copy-ctor implementieren?

  • E

    Oh, nein, sorry. Mein Beispiel ist falsch...

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

    0
  • K

    Kopier- und Move-Semantik für so eine Node-Klasse ergibt für mich gar keinen Sinn. Das ist eher die Sache der übergeordneten Tree-Klasse.

    0
  • E

    Hm, das ist bei mir jetzt halt ein Abwasch. Um das Beispiel von den Mengen weiterzuverwenden ist es eben so, dass der Top-Node auch markierte Zahlen hat. Und wenn ich in der Tree-Klasse so etwas wie Root-Node mache, muss ich nahezu alle Methoden daran weiterleiten. Oder man muss sich als Anwender stets den Root-Node holen und die Operationen darauf ausführen (der Baum kam erst später mit rein). Das finde ich auch nicht sonderlich schön.

    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?

    0
  • K

    Eisflamme schrieb:

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

    0
  • E

    Ich hab das mit den Mengen doch ziemlich gut auf ein Minimalbeispiel reduziert, denke ich. Genau das ist das im Originalcode auch, nur mit allen möglichen Zusatzsachen und Mengen, deren Einträge ich noch erläutern müsste. Aber die Details sind für die Implementierung oder mein Problem alle unwesentlich.

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

    0
  • C

    krümelkacker hat schon recht, du kannst logischerweise eh immer nur die root-node moven, weil du zum moven Besitz-"Rechte" brauchst, und an die kommste von außen erst mal nicht. Und wenn die Root-Node dann auch ein unique_ptr<node> und keine node ist, dann musst du nur den moven und kannst den ganzen anderen Kram aus der node-Klasse raus holen.

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

    0
  • E

    Hm, aber wenn ich einen Teilbaum in einen anderen Baum move, dann werden die Kinder eben an den Parent angeknüpft. Genau so wie, wenn ich bei einem echten Waldbaum einen Ast mit Zweigen abreiße und an einen anderen Baum dranklebe (also z.B. einen herauswachsenden Ast durch meinen gemoveten Teilbaum ersetze). Wieso ergibt das keinen Sinn? Man muss halt stets den Parent nachkorrigieren, aber jeder Ast hat über seine Kinder doch das Besitzrecht. Aber vielleicht versteh ich den Einwand nicht ausreichend. Die Untermengen müssen natürlich gemäß der Obermenge nachkorrigiert/reduziert werden.

    Stellt man sich das grafisch dar, kann es doch stets Sinn machen, Teilbäume irgendwo anders reinzumoven (über Drag&Drop). Intern muss halt erst ein neuer Teilbaum angelegt werden, in den kann dann der andere Teilbaum gemoved werden. Oder findet ihr das Quatsch?

    Und die Anwendung einer Teilbaumkopie habe ich bei mir ebenso.

    Okay, dann geht die obige Syntax:

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

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

    aber natürlich nicht. Wie würdet ihr das denn dann nennen und wie würdet ihr die Schnittstellen basteln, um das umzusetzen?

    So oder anders?

    MengenBaum baum;
baum.wurzel().setzeZahl(10);
Menge& untermenge = baum.wurzel().erzeugeKind();
untermenge.setzeZahl(10);

// Kopie
Menge untermengenKopie = untermenge;

// Move
MengenBaum andererBaum = std::move(baum);

    Ich fand es nur wie gesagt praktisch, dass ich irgendjemandem eine Menge gebe und die Menge ihre Untermengen dann einfach hat und ich nicht noch eine Baumstruktur drumlegen muss. Findet ihr das nicht praktisch? Oder doch, aber das muss ich dann leider in Kauf nehmen?

    Edit: Hm, und diesen Baum zu serialisieren macht wirklich überhaupt keinen Spaß. Ein index-basierter Ansatz für Kenntnis des Parent und der Neighbors hat mittlerweile so viele Vorteile... man hat halt ne Indirektion mehr, aber die Performance ist hier eigentlich egal. Nur wenn man einem Teilbaum sagt "füge Mal was ein", muss der eben den Parent kriegen, also müsste man ihm den Parent mit übergeben, das ist ja auch Käse.

    0
Anmelden zum Antworten