Missing clone_ptr / value_ptr
-
Bin ich eigentlich der einzige, dem der smart pointer fehlt, der klont?
Manchmal fehlt mir einfach die Copy Semantik für einfache polymorphe Objekte.
copy assignment und copy construct will ich nicht überladen und shared_ptr ist einfach die falsche Wahl, weil ich ja nicht teilen will.Ich habe mir jetzt ein selbst implementiert, der fast genauso aussieht wie der unique_ptr, nur neben move auch copy erlaubt. Benötigt dafür aber eine virtuelle clone Methode. Die Notwendigkeit entstand durch eine Vererbungshierarchie und hätte ich unique_ptr verwendet, hätte sich das durch das komplette Programm durchgezogen.
- Wieso gibt es sowas nicht im Standard? (Außer Leute daran zu hindern, das Ding zu missbrauchen, weil sie move Semantik nicht verstanden haben :D)
- Wieso finde ich nicht öfters Leute die nach sowas fragen?
- Übersehe ich irgendwas, das den value_ptr völlig unnötig macht?
-
5cript schrieb:
Die Notwendigkeit entstand durch eine Vererbungshierarchie und hätte ich unique_ptr verwendet, hätte sich das durch das komplette Programm durchgezogen.
Erklär!
-
Vielleicht bin ich auch nur ein bisschen kriminell in meinen Datenstrukturen.
Recursive struktur zur Abbildung von Markup Listen, wie man sie in Wikis findet. Namen sind leicht abgeändert.
struct ListTextLine : public ListElement { std::string data; // clone }; // Ich finde es affig für sowas triviales copy assignment, copy construction // getter und setter usw zu schreiben. Diese structs haben auch keine Methoden außer clone und damit keine Invarianz oder internal state, den ich schützen müsste. struct List : public ListElement { ListType type; std::vector <unique_ptr <ListElement>> elements; // Ups ich müsste hier die Operatoren einbauen. }; class WikiList : public MarkupComponent { public: std::string toMarkup() override; ParsingResult fromMarkup(std::string const& mu) override; // ... private: List data; //<- Ups ich bin plötzlich unkopierbar }; // Somewhere in my code: Ups ich muss WikiListen hin und her schieben.
EDIT: Einfach durch die Benutzung meines value_ptr muss ich gar keinen weiteren code schreiben oder sonstige Ged
EDIT 2: Well, dadurch, dass beide eine clone methode haben, hätte ich auch die Operatoren schreiben können, bzw spätestens in WikiList
-
Einfachste Lösung in dem Fall wohl:
std::list
stattstd::vector<unique_ptr<...>>
und schon wieder fertig...
-
dot schrieb:
Einfachste Lösung in dem Fall wohl:
std::list
stattstd::vector<unique_ptr<...>>
und schon wieder fertig...Geht im gezeigten Beispiel nicht, da Polymorphie im Spiel ist und wir Pointer auf
ListElement
brauchen.Zur Frage an sich: Das gleiche habe ich mich auch schonmal gefragt. Zwar hatte ich bisher noch keine Situation in der ich diese Konstruktion brauchte und habe mir daher selbst noch keine Implementation geschrieben aber warum das nicht im Standard ist frage ich mich auch. Nichtmal boost scheint sowas zu haben. Wobei ich mich gerade frage wie du das Objekt kopierst wenn du nur einen Pointer auf die Basisklasse hast?
-
sebi707 schrieb:
dot schrieb:
Einfachste Lösung in dem Fall wohl:
std::list
stattstd::vector<unique_ptr<...>>
und schon wieder fertig...Geht im gezeigten Beispiel nicht, da Polymorphie im Spiel ist und wir Pointer auf
ListElement
brauchen.In dem Fall muss dein Smartpointer zum "Kopieren" aber irgendeine Methode einer abstrakten Klasse aufrufen, dass sich sowas nicht in einer Standardbibliothek findet, sollte jetzt keine Überraschung sein!? Wie sollte die Methode standardmäßig heißen und wieso nicht anders? Was gibt sie zurück? Wie wird das von der Methode zurückgegebene Ding wieder gelöscht? Sowas baust du dir, wenn du es wirklich brauchst (was verhältnissmäßig selten der Fall sein sollte) selbst, in einer Standardbibliothek hat sowas imo absolut nichts verloren...
-
@dot
Könnte man gleich lösen wie beishared_ptr
der Deleter gemacht ist: Funktor der beim Erzeugen mit angegeben werden muss. Dass es das nicht gibt liegt mMn. eher daran dass man es nicht so oft braucht.
-
man könnte natürlich auch darüber nachdenken ob im OP gezeigtem Beispiel eine std::vector die geeignet Container Klasse ist oder nicht doch durch eine eigenen Container Wrapper ersetzt werdend sollte.
nachdem element_type und deleter_type vom unique_ptr bekannt sind ist das clone wenn gewollt eine freie Funktion die einmal entwickelt und dann für alle Objekte gilt die copy constructable sind,
'künstliche' clone Methoden werden unnütz.
Und das ist eigentlich, nach meinem Geschmack, eleganter.
-
hustbaer schrieb:
@dot
Könnte man gleich lösen wie beishared_ptr
der Deleter gemacht ist: Funktor der beim Erzeugen mit angegeben werden muss. Dass es das nicht gibt liegt mMn. eher daran dass man es nicht so oft braucht.Könnte man machen, zusätzlich zum Deleter natürlich noch eine Policy für welche Methode jetzt aufzurufen ist. Die Clone-Methode returned natürlich einen
std::unique_ptr
, denn deren Produkt muss den Besitz am Objekt mitnehmen. Derclone_ptr
muss natürlich einen zumunique_ptr
kompatiblen Deleter und passenden Konstruktor haben. Dann kannst du das Produkt der Clone-Methode zusammen mit dem Deleter in deinenclone_ptr
reinmoven. Imo ist das einfach ein viel zu seltener und zu spezieller Usecase als dass ich sowas in einer Standardbibliothek würde sehen wollen, da fallen mir echt beliebig viele Dinge ein, die ich eher vermissen würde als sowas. Vor allem kann man es sich einfach in 20 Zeilen selbst basteln, wenn man es wirklich einmal haben zu müssen meint (ich könnte mich gerade nicht erinnern, wann ich solch ein Konstrukt in C++ mal wirklich gebraucht hätte)...Edit: Ok, die Clone-Methode kann wohl auch einfach einen
clone_ptr
returnen. Anyways, imo dennoch viel zu speziell als dass ich das in der Standardbibliothek vermissen würde...
-
Die Clone-Methode könnte auch einfach nen Raw-Pointer zurückgeben. "Muss" ist da gar nix,
new
liefert auch nen Raw-Pointer zurück und man kann damit arbeiten.dot schrieb:
Imo ist das einfach ein viel zu seltener und zu spezieller Usecase (...)
Ja, sehe ich genau so.
-
kurze_frage schrieb:
nachdem element_type und deleter_type vom unique_ptr bekannt sind ist das clone wenn gewollt eine freie Funktion die einmal entwickelt und dann für alle Objekte gilt die copy constructable sind,
'künstliche' clone Methoden werden unnütz.
Und das ist eigentlich, nach meinem Geschmack, eleganter.Als Template-Parameter bekannt ist beim Klonen ja nur der "static type". Klonen musst du aber den "dynamic type".
Dazu könnte man, analog dazu wasshared_ptr
für den Deleter macht, einen "Default-Kloner" beim Initialisieren/Resetten desclone_ptr
erzeugen und mit abspeichern. Dieser kann den dynamischen Typ klonen, da an dieser Stelle ja der dynamische Typ bekannt ist. Bzw. den Typ der ursprünglich an den Ctor bzw. die Reset-Funktion übergeben wurde.Das nächste Problem das man dabei hätte wäre dann: der Kloner kann nur einen Zeiger zurückgeben auf einen Typ
T
. Egal wie manT
wählt, sobald man Casts unterstützen will steht man vor dem Problem dass man irgendwann nenclone_ptr<U>
hat, der Kloner aber nenT*
zurückgibt. Dummerweise ist dabei aberT
demclone_ptr
nicht bekannt undU
dem Kloner nicht bekannt. Wei also den Zeiger konvertieren?Rein technisch würde ich sagen: sollte gehen. Man speichert einfach in jedem
clone_ptr
den Offset (inchar
s) zwischen dem gespeicherten Zeiger und dem originalenT*
(mitT
=dynamischer Typ des Objekts). Da der Kloner immerT*
zurückgibt, kann man dann aus einemclone_ptr<U>
einen weiterenclone_ptr<U>
klonen, indem man einfach den Offset auf den Rückgabewert des Kloners draufrechnet. Das würde dann sogar soweit funktionieren, dass man, wenn man einenclone_ptr<U>
auf das 27.U
-Subobjekt einesT
hat (dreaded diamond und so), und davon ausgehend klont, man als Ergebnis wieder einenclone_ptr<U>
auf das 27.U
-Subobjekt des neuenT
bekommt.Wo ich mir aber nicht so sicher bin ist ob der Standard Zeigerakrobatik dieser Art erlaubt.
-
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, wobeicow<Derived>
dann incow<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.
-
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
-
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ß
Wernervielleicht 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.
-
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 einunique_ptr
dort nicht machen nicht kann?
-
@dot
Denvalue_ptr
bzw.clone_ptr
brauchst du wenn du Value-Semantik mit Polymorphie kombinieren willst.
-
Ist mir schon klar, nur angeblich soll der jetzt auch ohne Polymorphie was bringen und das versteh ich grad nicht!?
-
Das hat er doch gerade geschrieben, du musst den Copy-Ctor nicht implementieren.
StattFoo::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.
-
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 einclone()
Teil haben zu müssen, den Copy C'tor private oder protected implementiert (oder defaulted) und dannauto clone() const { return std::make_unique<Blub>(*this); }
macht, weil wieso würde man irgendwas anderes machen...