Von da habe ich den folgenden Code:

struct Base {
    virtual Base* clone() const { return new Base(this); }
};

struct Derived : Base {
    virtual Base* clone() const { return new Derived(this); }
};

Rohe Zeiger zurückgeben ist heutzutage allerdings out.

Schöner wäre so etwas:

struct Base {
    virtual unique_ptr<Base> clone() const { return make_unique<Base>(this); }
};

struct Derived : Base {
    // invalid covariant return type for ‘virtual std::unique_ptr<Derived> Derived::clone() const’
    virtual unique_ptr<Derived> clone() const { return make_unique<Derived>(this); }
};

Ich will quasi die erste Variante einfach mit unique_ptr s. Auf die Kovarianz bin ich angewiesen. Gibt es da einen eleganten Weg?

struct Base {
    virtual Base* clone() const { return new Base(this); }
};

struct Derived : Base {
    virtual Derived* clone() const { return new Derived(this); }
};

Was dir aber als gute Möglichkeit bleibt, ist ein privates virtual Base*/Derived* cloneX() zu schreiben und ein public unique_ptr<Base/Derived> cloneY() diese aufrufen zu lassen.

template <class T>
auto clone(T* obj) -> std::unique_ptr<typename std::remove_pointer<decltype(obj->clone())>::type>
{
  return std::unique_ptr<typename std::remove_pointer<decltype(obj->clone())>::type>(obj->clone());
}

Ja, direkt std::unique_ptr zurückgeben wirds nicht spielen. Ich würde wohl was in der Richtung versuchen:

template <class T>
auto clone(T* obj) -> std::unique_ptr<typename std::remove_pointer<decltype(obj->clone())>::type>
{
  return std::unique_ptr<typename std::remove_pointer<decltype(obj->clone())>::type>(obj->clone());
}

decltype nimmt nur den statischen Typ, insofern ist decltype(obj->clone()) immer decltype(T*).

template <class T> 
std::unique_ptr<T> clone(T* obj)
{ 
  return std::unique_ptr<T>(obj->clone()); 
}

ist natürlich viel lesbarer...

template <typename T>
std::unique_ptr<T> clone(T const& obj)
{
  return std::unique_ptr<T>(obj.clone());
}

Geht scheinbar nicht als Memberfunktion, danke vielmals.

struct Base { 
    unique_ptr<Base> clone() const { return cloneMe(); } 
private:
    virtual Base* cloneMe() const { return new Base(*this); }
}; 

struct Derived : Base { 
    unique_ptr<Derived> clone() const { return cloneMe(); } 
private:
    virtual Derived* cloneMe() const { return new Derived(*this); }
};

So muss du deinen bestehenden Client-Code auch nicht anpassen.

? Ich habe doch eine saubere Möglichkeit genannt

Dann hab ich das falsch verstanden. Ich dachte clone würde bei jeder Klasse anders heissen.
An das hab ich gar nicht gedacht, top

Ist natürlich auch eine Lösung, hat halt den Nachteil, dass man in jeder Klasse, die ein kovariates clone() unterstützten soll die entsprechende Methode extra definieren muss.

Ach, ein STRG+R tuts auch Es ist halt eine Änderung im Code gewünscht und die erfordert eben Arbeit, da kommt man nicht drumherum. Hauptsache der Client erleidet daraus keinen Nachteil.

Herb Sutter schrieb:

Guideline #2: Prefer to make virtual functions private.

unique_ptr<Base> clone() const { return cloneMe(); } 
unique_ptr<Derived> clone() const { return cloneMe(); }

Da scheine ich ja was vergessen zu haben Einfach return unique_ptr<T>(cloneMe()) daraus machen. Btw, corian welchen Compiler benutzt, dass du schon make_unique hast?

Da scheine ich ja was vergessen zu haben Einfach return unique_ptr<T>(cloneMe()) daraus machen. Btw, corian welchen Compiler benutzt, dass du schon make_unique hast?

Das make_unique hab ich mir selber geschrieben.
Ein return {cloneMe()}; reicht auch übrigens schon.

Ein return {cloneMe()}; reicht auch übrigens schon.

unique_ptr's Konstruktor ist explicit, zumindest sollte es das bei dir sein und folgedessen obiger Code nicht funktionieren. Wenn das oben bei dir wirklich funktioniert, dann blitzt und donnert es aber gewaltig mit der RAII-Philosophie.

corian schrieb:

Ein return {cloneMe()}; reicht auch übrigens schon.

unique_ptr's Konstruktor ist explicit, zumindest sollte es das bei dir sein und folgedessen obiger Code nicht funktionieren. Wenn das oben bei dir wirklich funktioniert, dann blitzt und donnert es aber gewaltig mit der RAII-Philosophie.

Ich war mir vorhin nicht sicher, ob diese Syntax wirklich nicht mit explicit Konstruktoren nutzbar ist und habe das nachgeguckt. Ein "return {...};" ist eine copy-list-initialization. Mit dieser kann man keine explicit Konstruktoren aufrufen. Du hast also Recht.