Missing clone_ptr / value_ptr

krümelkacker

Ich hatte mir mal einen smart pointer für copy-on-write gebastelt ( cow<T> ), dem ich auch Laufzeit-Polymorphie beibringen wollte (T durfte abstrakt sein, wobei cow<Derived> dann in cow<Base> konvertierbar war), just for fun. Gebraucht habe ich das dann aber nie. Jedenfalls kann ich mich nicht dran erinnern, ihn tatsächlich eingesetzt zu haben. copy-on-write alleine ja. Aber nicht polymorph.

Werner Salomon

für den clone_ptr existiert bereits der Vorschlag N3339. Daraus ist aber anscheinend nichts geworden. Siehe noch hier http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3371.html) .. und danach ist er verschwunden.

Ich habe einen clone_ptr bisher nie gebraucht.

Gruß
Werner

kurze_frage

Werner Salomon schrieb:

für den clone_ptr existiert bereits der Vorschlag N3339. Daraus ist aber anscheinend nichts geworden. Siehe noch hier http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3371.html) .. und danach ist er verschwunden.

Ich habe einen clone_ptr bisher nie gebraucht.

Gruß
Werner

vielleicht ist der ja deswegen wieder verschwunden weil offensichtlich ist das wenn man value objects will soche auch verwenden sollte und auf dem heap herum kugelnde Objekte zum clonen doch sehr javaresk sind

Was aber nicht immer möglich ist. Hier ging es ja ganze Zeit um Polymorpie. Aber auch ohne kann es Sinn machen. Z.B. bei Datenstrukturen wie Linked Lists oder Bäumen. Wenn man die mit so einem value_ptr aufbauen würde braucht man sich nicht mehr um Copy Constructor kümmern.

dot

sebi707 schrieb:

Aber auch ohne kann es Sinn machen. Z.B. bei Datenstrukturen wie Linked Lists oder Bäumen. Wenn man die mit so einem value_ptr aufbauen würde braucht man sich nicht mehr um Copy Constructor kümmern.

Sehe nicht, wofür man dort einen solchen " value_ptr " brauchen würde. Was genau macht der, was ein unique_ptr dort nicht machen nicht kann?

hustbaer

@dot
Den value_ptr bzw. clone_ptr brauchst du wenn du Value-Semantik mit Polymorphie kombinieren willst.

dot

Ist mir schon klar, nur angeblich soll der jetzt auch ohne Polymorphie was bringen und das versteh ich grad nicht!?

hustbaer

Das hat er doch gerade geschrieben, du musst den Copy-Ctor nicht implementieren.
Statt

Foo::Foo(Foo const& other)
{
    if (other.m_left)
        m_left.reset(other.m_left->clone());
    if (other.m_right)
        m_right.reset(other.m_right->clone());
}

schreibst du einfach ... nix.
Nix schreiben ist einfacher. Und weniger fehleranfällig.

dot

Naja großartig, dann hast du deinen Copy C'tor halt clone() genannt, implementieren musst du es trozdem. Ich ging davon aus, dass es selbstverständlich ist, dass man, wenn man schon meint, so ein clone() Teil haben zu müssen, den Copy C'tor private oder protected implementiert (oder defaulted) und dann

auto clone() const { return std::make_unique<Blub>(*this); }

macht, weil wieso würde man irgendwas anderes machen...

Nein du brauchst auch keine clone Funktion. Alle Membervariablen werden durch den Aufruf ihres Copy Constructors kopiert und der value_ptr implementiert diesen eben so, dass nicht die Adresse kopiert wird sondern tatsächlich die Daten. Wobei wir ja schon diskutiert haben das dieser Kopiervorgang für polymorphe Objekte nicht so einfach ist. Ohne Polymorpie ist das allerdings trivial.

dot

Dafür brauch ich aber keinen value_ptr weil der Copy C'tor macht das doch schon!?

Aber falsch. Wenn du Raw Pointer benutzt kopiert er nur die Adressen und wenn du unique_ptr benutzt gibts gar keinen Default Copy Constructor weil unique_ptr Move only ist.

kurze_frage

nach dem ansehen von 'inheritance is the base class of evil' bin ich der Meinung das ich bis dahin immer viel zu viel polymorphe Objekte gebaut habe und deswegen alles so kompliziert wurde. Sean Parent legt da einfach seine value Objekte von unterschiedlichen Typen in den Container, sehr fesch die Methode!

Ansonst, mit nur einem Pointer auf die Base Klasse wird ohne weitere Info auch ein value_ptr Probleme haben irgendetwas brachbar zu kopieren, von selber geht da also nix.

dot

sebi707 schrieb:

Aber falsch. Wenn du Raw Pointer benutzt kopiert er nur die Adressen und wenn du unique_ptr benutzt gibts gar keinen Default Copy Constructor weil unique_ptr Move only ist.

Die Frage ist, wieso willst du "Pointer kopieren"? Wenn dein Typ Wertsemantik hat und du besitzende Zeiger drauf hast, hast du sehr wahrscheinlich was falsch gemacht...

hustbaer

dot schrieb:

Naja großartig, dann hast du deinen Copy C'tor halt clone() genannt, implementieren musst du es trozdem. Ich ging davon aus, dass es selbstverständlich ist, dass man, wenn man schon meint, so ein clone() Teil haben zu müssen, den Copy C'tor private oder protected implementiert (oder defaulted) und dann
auto clone() const { return std::make_unique<Blub>(*this); }
macht, weil wieso würde man irgendwas anderes machen...

Das wurde doch schon alles diskutiert: es sollte möglich sein dass der value_ptr den normalen Copy-Ctor verwendet.

dot schrieb:

Dafür brauch ich aber keinen value_ptr weil der Copy C'tor macht das doch schon!?

Wenn du mir zeigst wie du nen Baum oder ne verkettete Liste ohne Zeiger aufbaust...

dot

hustbaer schrieb:

dot schrieb:

Dafür brauch ich aber keinen value_ptr weil der Copy C'tor macht das doch schon!?

Wenn du mir zeigst wie du nen Baum oder ne verkettete Liste ohne Zeiger aufbaust...

Die Frage ist, wo ich dabei die Ziele irgendwelcher Pointer kopieren muss...

hustbaer

@dot
Meine Geduld wird gerade sehr strapaziert.

Wie kopierste deinen Baum denn?
Wie meinste kopiert sich std::set ?
Indem es Nodes kopiert, die Zeiger auf weitere Nodes haben, die auch wieder kopiert werden müssen usw.

dot

Wenn ich einen Typen mit Wertsemantik hab, steck ich die Objekte direkt in den Container, weil wieso würde ich eine sinnlose Indirektion haben wollen!? Wenn ich Typen mit Referenzsemantik hab, mach ich mir lieber eine Funktion, die mir per make_unique(**it) eine Deep Copy anfertigt (denn das ist die einzige Stelle, an der ich das brauche), bevor ich solch fragwürdige Konstrukte wie einen value_ptr in freie Wildbahn entlasse...

hustbaer

@dot
Vergiss vielleicht einfach mal den Begriff Zeiger.
Statt dessen denk an boost::optional .
Wenn wir polymorphie mal aussen vor lassen, dann ist das Ding worüber wir reden ein boost::optional welches rekursive Datenstrukturen erlaubt.

dot

Nun, dann kann man ja einfach boost::optional verwenden; wobei ich persönlich das niemals tun würde, weil ich nie wieder ruhig schlafen könnte...