sharry schrieb:

Und was soll

void Test2(SharedPtr<Base> test)

sein?

ÜBERGEBE NIE SMARTPOINTER ALS ARGUMENT (wenn du nicht weisst, was du tust)!

Das sollte

void Test2(Base const& test)

sein und dann ist dein Problem gelöst.

Handhabt ihr das alle so, das ihr nur Referenzen auf das Object übergebt und keine Referenzen auf den SmartPointer an sich?
Wenn ja, aus welchem Grund? Das man einen Unique_ptr nicht ohne weiteres übergeben kann, ist mir bewusst, aber eine (const) Referenz darauf ist möglich. Und so handhabe ich das eigentlich auch.

mfg

bei unique_ptr per Value. Wenn nicht, dann per (const) ref.

Einen unique_ptr per Value übergeben? Wie geht das denn? Kopieren geht doch nicht... oO
Oder meinst du moven?!
Und statt const& kann man auch gleich ne normale Referenz auf das Objekt nehmen.

Nur in seltenen Fällen braucht man shared_ptr<Object> const& oder unique_ptr<Object> (ja, das geht). In ganz seltenen Fällen, wenn man den Smartpointer ändern will, braucht man shared_ptr<Object>& oder unique_ptr<Object>& .

unique_ptr<Objekt> const& hingegen macht kein Sinn. Hat keinerlei Vorteile gegenüber Object* / Object const* / Object& / Object const& , nur Nachteile.

Die Aussage ist, dass wenn es möglich ist die Funktion mit einer const-Referenz auf das Objekt zu implementieren, das dann auch der beste Weg ist.

Und das ist einfach falsch.
Es sind verschiedene Dinge: Entweder ich uebergebe Besitz, oder eben nicht. Je nachdem entscheidet man.

sharry schrieb:

Die Aussage ist, dass wenn es möglich ist die Funktion mit einer const-Referenz auf das Objekt zu implementieren, das dann auch der beste Weg ist.

Und das ist einfach falsch.
Es sind verschiedene Dinge: Entweder ich uebergebe Besitz, oder eben nicht. Je nachdem entscheidet man.

Stimmt so doch.

Ist es möglich übergebenden Besitz mit einer const-Referenz zu implementieren? Nein. Also Referenz auf Smartpointer.

Einen unique_ptr per Value übergeben? Wie geht das denn? Kopieren geht doch nicht... oO

Das hier funzt by design:

#include <iostream>
#include <memory>

using std::unique_ptr;

unique_ptr<int> source()
{
   unique_ptr<int> p (new int(42));
   return p;
}

void sink(unique_ptr<int> p)
{
   std::cout << "*p is " << *p << '\n';
}

int main()
{
  sink(source());
}

und das ist gut so.

Wenn Besitz uebergeben werden soll, dann Smartpointer per const ref im Falle von Reference Counting, bei unique_ptr per Value. Wenn nicht, dann per (const) ref.

wobei seit move semantics ich auch einen shared_ptr per value übergeben würde. Wenn also der "Besitz" übergeben wird und die Funktion den shared_ptr irgendwo anders speichern will, dann hast du bei folgenden Möglichkeiten

• ref-auf-const
• ref-auf-const und rvalue-ref überladen
• pass by value

beim letzten Punkt keine unnötigen Kopien (die Funktion kann den shared_ptr dahin moven, wo sie ihn haben will) und das ohne dass man die funktion überladen muss. Das Moven eines shared_ptrs ist, denke ich mal, vernachlässigbar. Jedenfalls muss da der Referenzzähler nicht angefasst werden.

Statt einer Referenz in anderen Fällen finde ich u.U. einen Zeiger auch sinnvoll. Was ich da nehme hängt u.a. davon ab, ob ich möchte, dass man beim Aufruf der Funktion sehen kann, dass ein Objekt nicht per Wert übergeben wird. Das ist ja im Falle von Referenzen nicht so offensichtlich, wenn man die Deklaration der Funktion nicht vor Augen hat. Und das möchte ich typischerweise dann, wenn die Funktion die Adresse des Objekts für länger irgendwo speichert -- nicht "besitzend" sondern nur "kennend"; denn ich erwarte i.A. nicht, dass eine Funktion, die eine Referenz entgegen nimmt, die Adresse des Objekts irgendwo speichert. Offensichtliche Ausnahme ist std::ref und std::cref, wobei das da allerdings klar sein dürfte, was sie macht.

Warum moven, wenn mans fuer lau bekommen kann? Sinnlos.

Du scheinst da nur an einen bestimmten Fall zu denken, nämlich den, in dem das Funktionsargument ein Lvalue ist. In dem Fall hätte man bei pass-by-value ein zusätzliches Move. Ein Move ist allerdings billig. Wenn das Argument ein Rvalue ist, hast du in deinem ref-auf-const Fall eine unnötige Kopie. Eine Kopie ist teuerer. Möchtest du, dass ich dazu ein Beispiel schreibe und erkläre in welcher Situation was wo kopiert und gemoved wird, oder glaubst du mir das jetzt auch so? Vielleicht denkst du ja selbst nochmal ein bisschen drüber nach. Die Fälle, die unterschieden werden sollten, sind:

• Argument ist ein Lvalue
• Argument ist ein Rvalue, Compiler führte copy-elision durch
• Argument ist ein Rvalue, Compiler hat die copy-elision nicht hinbekommen

Die optimale Lösung im Sinne der Reduzierung von unnötigen Kopien und Moves bekommst du nur mit der Überladung ref-auf-const und rvalue-ref. Allerdings spare ich mir gerne die Überladung und nehme ein ggf. unnötiges Move bei pass-by-value in Kauf. Klar soweit?