Missing clone_ptr / value_ptr
-
dot schrieb:
Nun, dann kann man ja einfach
boost::optional
verwenden;Nein, kannst du nicht weil das originale
boost::optional
eben keine rekursiven Datenstrukturen unterstützt.dot schrieb:
wobei ich persönlich das niemals tun würde, weil ich nie wieder ruhig schlafen könnte...
*facepalm*
OK.
-
hustbaer schrieb:
dot schrieb:
wobei ich persönlich das niemals tun würde, weil ich nie wieder ruhig schlafen könnte...
*facepalm*
OK.Sorry, ich war gerade etwas verwirrt und hab
boost::optional
mitboost::variant
verwechselt (die Verwendung von sowas wie dem letzterem ist imo als Verbrechen anzusehen). Ich versteh worauf du hinauswillst, nur imo zahlt es sich nicht aus, extra einenvalue_ptr
zu schreiben, nur weil ich in der einen Zeile in der einen Funktion, die eine Deep-Copy machen soll eine Kopie vom Ziel eines Pointers anfertigen will. Ich sag ja nicht, dass ich mir absolut keine Situation vorstellen kann, wo einvalue_ptr
vielleicht Sinn machen würde, nur ist eine solche Situation wirklich extremst selten...
-
dot schrieb:
Vielleicht ein kleiner Tipp: Dein
Clone
Typ wird in der Regel leer sein, statt diesemstd::tuple
Konstrukt (wieso auch immer dasstd::tuple
) besser private vonClone
ableiten und sich auf Empty-Base-Class-Optimization verlassen, sonst wird deinclone_ptr
zwangsweise immer größer sein als ein einfacher Pointer und damit unnötig ineffizient beim Herumreichen...Du hast meinen Beitrag offensichtlich nur überflogen. Genau das Thema habe ich sowohl berücksichtigt als auch angesprochen. Ich verlasse mich darauf, dass
std::tuple
mir die EBO abnimmt. Ist zwar nicht garantiert, aber bei mir klappt's. Ich habe absichtlich keine Vererbung hier eingesetzt, weil das die Menge der Clone-Typen auf "class types" einschränken würde. Man würde hier vielleicht auch einen Funktionszeiger nutzen wollen. Das ginge dann mit der Vererbung so nicht bzw nur dann, wenn man noch eine extra Klasse baut:template<class T> struct wrapper { T value; }; template<class T, class Clone = default_clone> class clone_ptr : wrapper<Clone> { ...
-
dot schrieb:
Sorry, ich war gerade etwas verwirrt und hab
boost::optional
mitboost::variant
verwechselt.OK, dann verstehe ich dein Kommentar
-
krümelkacker schrieb:
...
Verstehe. So einen Wrapper wollte ich gerade vorschlagen...
Dass deine
std::tuple
Implementierung leere Elemente kollabiert, überrascht mich ehrlich gesagt, denn das würde bedeuten, dass zwei Elemente einesstd::tuple
die selbe Adresse haben können, was ich als Defekt im Standard ansehen würde, wenn der das tatsächlich erlaubt...Edit: Grad getestet: in Visual C++ 2015 wird ein solches Tuple auf x64, wie ich erwartet hätte, 16 Byte groß...
-
Man könnte
boost::compressed_pair
verwenden
http://www.boost.org/doc/libs/1_60_0/libs/utility/doc/html/compressed_pair.htmlz.T.
tuple
hab' ich das gefunden:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2533.htmltuple
permits an additional space-saving optimization, as exploited in the boostcompressed_pair
library.Bei
std::pair
ist das AFAIK nicht erlaubt.
Vermute mal dass das der Grund ist warum krümelkackertuple
stattpair
verwendet hat.
-
Gut zu wissen, konnte im Standard auf den ersten Blick weder eine explizite Erlaubnis, noch ein explizites Verbot einer solchen Optimierung finden. Auf jeden Fall eine interessante Frage, hoffentlich weiß jemand mehr...
-
Das ist meine Variante. (möglicherweise sind da (noch) Fehler drin.)
https://github.com/5cript/SimpleUtil/blob/master/value_ptr/value_ptr.hpp
-
Also das sieht nicht richtig aus
static_assert(!std::is_pointer<deleter_type>::value, "constructed with null function pointer deleter");
-
Oh ja stimmt, die sind fast alle copy + paste + "no brain" falsch.
-
5cript schrieb:
struct List : public ListElement { ListType type; std::vector <unique_ptr <ListElement>> elements; };
Designfehler. Hier nimmt man Composition, nicht Inheritance.
-
5cript schrieb:
Bin ich eigentlich der einzige, dem der smart pointer fehlt, der klont?
Manchmal fehlt mir einfach die Copy Semantik für einfache polymorphe Objekte.Mhhm. Mir nicht. Der Yielcontainer hat dann wohl meistens yuf'llig lokalere Lebensdauer und verwaltet nur nichtbesityende Yeiger.