Missing clone_ptr / value_ptr

dot

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 mit boost::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 einen value_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 ein value_ptr vielleicht Sinn machen würde, nur ist eine solche Situation wirklich extremst selten...

krümelkacker

dot schrieb:

Vielleicht ein kleiner Tipp: Dein Clone Typ wird in der Regel leer sein, statt diesem std::tuple Konstrukt (wieso auch immer das std::tuple ) besser private von Clone ableiten und sich auf Empty-Base-Class-Optimization verlassen, sonst wird dein clone_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>
{ ...

hustbaer

dot schrieb:

Sorry, ich war gerade etwas verwirrt und hab boost::optional mit boost::variant verwechselt.

OK, dann verstehe ich dein Kommentar

dot

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 eines std::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ß...

hustbaer

Man könnte boost::compressed_pair verwenden
http://www.boost.org/doc/libs/1_60_0/libs/utility/doc/html/compressed_pair.html

z.T. tuple hab' ich das gefunden:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2533.html

tuple permits an additional space-saving optimization, as exploited in the boost compressed_pair library.

Bei std::pair ist das AFAIK nicht erlaubt.
Vermute mal dass das der Grund ist warum krümelkacker tuple statt pair verwendet hat.

dot

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

5cript

Das ist meine Variante. (möglicherweise sind da (noch) Fehler drin.)
https://github.com/5cript/SimpleUtil/blob/master/value_ptr/value_ptr.hpp

hustbaer

Also das sieht nicht richtig aus

static_assert(!std::is_pointer<deleter_type>::value,
	               "constructed with null function pointer deleter");

5cript

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.

volkard

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.