Ich programmiere schon seit ein paar Jahren mit C++ und ich mache mir Gedanken, wie ich am besten die Member einer Klasse initialisieren kann. Bisher habe ich im Konstruktor meistens const Referenzen verwendet. Ich möchte möglichst effizient arbeiten und einen gewissen Leitfaden folgen. Ausnahmen bestätigen die Regeln.

class TestClass
{
    std::string Wert1;
    int Wert2;
public:
    TestClass(
        const std::string& wert1,
        const int wert2
    ) : Wert1(wert1),
        Wert2(wert2)
    {};
};

Das sorgt natürlich für Kopien. Kann manchmal gewünscht sein oder auch nicht. Hat natürlich den Vorteil, das die Variablen des Aufrufers nicht verändert werden und er diese weiter verwenden kann. Aber wenn der Aufrufer die Objekte direkt in der Parameterübergabe vom Konstruktor übergibt, werden unnötige Kopien gemacht.

TestClass temp(
        std::string("ABC"),
        5
    );

Die temporäre Variable/Objekt vom Typ String wird kopiert und dann zerstört. In letzter Zeit habe ich mir den Move Operator angeschaut.

TestClass(
        std::string wert1,
        int wert2
    ) : Wert1(std::move(wert1)),
        Wert2(std::move(wert2))
    {};

In diesem Fall werden die Werte gemovt ohne kopiert zu werden. Wenn der Aufrufer bei der Parameterübergabe diese Werte in den Konstruktor movt, werden auch keine lokalen Kopien in der Parameterliste erzeugt und Kopien werden vermieden. Allerdings muss der Aufrufer dann auch explizit die Variablen in den Konstruktor beim Erzeugen des Objekts moven.

Beide Varianten haben Vor- und Nachteile und ich würde mal eure Erfahrungen dazu hören, was ihr macht oder machen würden. Ob ihr einen Leitfaden habt, dass ihr bei Klassen meist movt oder wie ich immer mit const Referenzen und Kopien arbeitet?
Ich könnte natürlich auch immer 2 Konstruktoren machen. Einen der ByValue die Variablen annimmt und daher das moven unterstützt und einen der die Variablen ByConstReference annimmt.

In diesem Fall werden die Werte gemovt ohne kopiert zu werden. Wenn der Aufrufer bei der Parameterübergabe diese Werte in den Konstruktor movt, werden auch keine lokalen Kopien in der Parameterliste erzeugt und Kopien werden vermieden. Allerdings muss der Aufrufer dann auch explizit die Variablen in den Konstruktor beim Erzeugen des Objekts moven.

Nein, der Aufrufer muss nur dann explizit moven, wenn er auch möchte, dass die Klasse das Objekt, bzw. die dahinter stehenden Ressourcen "in Besitz" nimmt. Z.B.

std::string s = "ABC";
TestClass temp(std::move(s),  5);
// Ich will hier nichts mehr mit s machen und möchte, dass TestClass 
// den String übernimmt.

Das dürfte jedoch eher selten der Fall sein. Meistens will man ohnehin eine separate Kopie in dem neuen Objekt haben, d.h. man braucht auch kein std::move, da man sowieso einmal kopieren muss:

std::string s = "ABC";
TestClass temp(s,  5);
// Ich brauche s hier noch.

Eine temporäres Objekt wie in diesem Fall:

TestClass temp(std::string("ABC"), 5);

oder auch

TestClass temp("ABC", 5);

Ist sowieso ein xvalue und damit ein rvalue, der an den bereits vorhandenen Move-Konstruktor des std::string binden kann. Da braucht man ebenfalls kein std::move, denn std::string(std::string&&) movt hier bereits automatisch.

Insofern ist die zweite Variante, den String By Value entgegenzunehmen und während der Initialisierung in den Daten-Member zu moven m.E. eine gute Lösung, um überflüssige Kopien zu vermeiden. Für den int ist das hier nicht notwendig, da den zu kopieren praktisch nichts kostet, aber schlechterer Code wird damit auch nicht erzeugt (lediglich überflüssige Tipparbeit).

Nein, der Aufrufer muss nur dann explizit moven, wenn er auch möchte, dass die Klasse das Objekt, bzw. die dahinter stehenden Ressourcen "in Besitz" nimmt. Z.B.

Ja das ist mir klar. Hab es etwas unklar beschrieben.

In meinem aktuellen Projekt auf der Arbeit habe ich teilweise einige Objekte aus einer Datenbank, die mit anderen Tabellen verknüpft sind und eine 1 zu n Beziehung haben. Die Objekte aus dem Left Join sammel ich in Vektoren über eine Schleife und übergebe sie dann den "Mutter" Objekt. Bisher habe ich in die Vektoren im Konstruktor immer als const Referenz angeommen und damit unnötige Kopien gemacht. Die Vektoren danach habe ich nicht mehr weiter verwendet.

Ich hab mich dann mit dem Move Konstruktoren und Operator(en) auseinander gesetzt und gemerkt, dass ich beim Moven unnötige Kopien vermeiden kann.
Ein Kollege von mir in der Arbeit nimmt in seinen Konstruktoren fast alles per Value an und movt es dann in die Member, wenn er es in den Membern braucht.

@Finnegan sagte in Member im Konstruktor per Move oder Copy initialisieren?:

Insofern ist die zweite Variante, den String By Value entgegenzunehmen und während der Initialisierung in den Daten-Member zu moven m.E. eine gute Lösung, um überflüssige Kopien zu vermeiden. Für den int ist das hier nicht notwendig, da den zu kopieren praktisch nichts kostet, aber schlechterer Code wird damit auch nicht erzeugt (lediglich überflüssige Tipparbeit).

Das man ein int nicht moven kann bzw. muss ist mir klar, aber der Vollständigkeit Halber habe ich es dennoch davor gesetzt.

Vermeidest du persönlich const Referenzen als Parameter in Konstruktoren(vom Copy Konstruktor abgesehen)?

Vermeidest du persönlich const Referenzen als Parameter in Konstruktoren(vom Copy Konstruktor abgesehen)?

Wenn das Objekt eine eigene Kopie von dem Parameter z.B. in einer Member-Variablen bekommen soll, mache ich es wie deine zweite Variante. By Value und dann move. Ansonsten ist bei mir auch erstmal const& Standard.

By Value + Move ist erstens ein sehr simples Pattern und hat zweitens den Vorteil, dass der Anwender entscheiden kann, ob er moven will oder nicht. Wenn man als const& entgegennimmt, wird dem Anwender nämlich die Kopie aufgezwungen. Alternativ kann man auch mit std::string&&-Parametern rumhantieren, das macht es aber nur unnötig kompliziert und damit lässt sich bestenfalls ein ohnehin recht billiges Move einsparen.

Und natürlich geht das auch analog zu std::string mit einem std::vector und allen anderen Typen, die sich sinnvoll "moven" lassen.

Foo::Foo(std::shared_ptr<Logger> logger, int a, int b, int c, int d) :
    m_logger(std::move(logger)),
    m_component1(a),
    m_component2(m_logger, b),
    m_component3(c, d),
    ...
    ... {
...

Kann man so machen. Bringt aber nicht viel, weil die Initialisierung hier vermutlich schon so teuer ist, dass die 2 atomic Instructions die man sich bei der std::shared_ptr Kopie spart relativ gesehen nicht viel ausmachen. Umgekehrt kann man schnell den Fehler machen m_component2(logger, b) statt m_component2(m_logger, b) zu schreiben. Bzw. wenn die Reihenfolge der Membervariablen nicht passt gibt's auch ein Problem. Daher verwende ich in solchen Fällen eher const& - weil ich da Lesbarkeit und Wartbarkeit für wichtiger halte als 20 oder 30 eingesparte CPU Zyklen.

In deinem Beispiel wo nur ein std::string und ein int übergeben werden finde ich "by value + move" aber eine gute Lösung. Aus den von @Finnegan beschriebenen Gründen.

Wobei es immer darauf ankommt wie performance-kritisch etwas ist. Wenn das die zentrale Klasse in deiner Anwendung ist was Performance angeht, dann könnte es Sinn machen einen Konstruktor mit std::string&& und einen mit std::string const& zu machen. Wobei der std::string&& Konstruktor dann vermutlich auch inline sein sollte. In dem Fall wäre es aber auch wichtig einen Performance-Vergleich zu machen um zu sehen was wirklich schneller ist. Denn da kann man sich auch schnell mal verschätzen

[...] dann könnte es Sinn machen einen Konstruktor mit std::string&& und einen mit std::string const& zu machen. [...]

Mit dem "und einen" lugt da breits ein kombinatorischer Alptraum über den Horizont, wenn man es mal mit mehr als einem Parameter zu tun hat, den man gerne moven möchte ... auch ein Argument für By-Value+Move

Selbst wenn man nicht auf bereits existierende Move-Konstruktoren wie bei std::string zurückgreifen kann und die selbst implementieren muss, ist das am Ende immer noch nur eine Funktion pro Klasse. Mit den Rvalue-Referenz-Parametern spart man hingegen nur einen Move im Vergleich zu By-Value+Move (den, mit dem der Parameter initialisiert wird oder der Move in die Member-Variable, wenn kopiert werden soll).

Für wirklich "heisse" Funktionen kann man das sicher rechtfertigen, für alle anderen ist By-Value+Move allerdings meiner Meinung nach so simpel, dass es man schon fast ein gutes Argument braucht es nicht zu verwenden. Aber eben nur, wenn man auch eine eigene Kopie des Parameters haben will, sonst const&.

Mit dem "und einen" lugt da breits ein kombinatorischer Alptraum über den Horizont, wenn man es mal mit mehr als einem Parameter zu tun hat, den man gerne moven möchte ... auch ein Argument für By-Value+Move

Ich teile deine Meinung. Das Thema wäre für mich dann abgeschlossen. Vielen Dank für eure beiden Antworten und Meinungen.

Für wirklich "heisse" Funktionen kann man das sicher rechtfertigen, für alle anderen ist By-Value+Move allerdings meiner Meinung nach so simpel, dass es man schon fast ein gutes Argument braucht es nicht zu verwenden.

Sehe ich ähnlich.

Wobei mir gerade ein Detail einfällt - etwas was viele vermutlich gar nicht wissen: "by value" (mit oder ohne move) erfordert u.U. (je nach Calling Convention) die Generierung eines dtor Aufrufs pro Funktionsaufruf. Was auch wieder etwas Overhead und vor allem Code-Bloat erzeugt. Das ist in den meisten Fällen vermutlich auch egal - aber es gibt Spezialfälle wo es hilfreich sein kann wenn man das weiss. (Wir haben z.B. an einigen Stellen in unseren Programmen Funktionen die hundert- bis tausendfach kleine Hilfsfunktionen aufrufen um eine Datenstruktur aufzubauen. Da kann sich das dann schnell negativ auf die Code-Grösse auswirken.)

@Finnegan sagte in Member im Konstruktor per Move oder Copy initialisieren?:

Für wirklich "heisse" Funktionen kann man das sicher rechtfertigen, für alle anderen ist By-Value+Move allerdings meiner Meinung nach so simpel, dass es man schon fast ein gutes Argument braucht es nicht zu verwenden.

Sehe ich ähnlich.

Wobei mir gerade ein Detail einfällt - etwas was viele vermutlich gar nicht wissen: "by value" (mit oder ohne move) erfordert u.U. (je nach Calling Convention) die Generierung eines dtor Aufrufs pro Funktionsaufruf. Was auch wieder etwas Overhead und vor allem Code-Bloat erzeugt. Das ist in den meisten Fällen vermutlich auch egal - aber es gibt Spezialfälle wo es hilfreich sein kann wenn man das weiss. (Wir haben z.B. an einigen Stellen in unseren Programmen Funktionen die hundert- bis tausendfach kleine Hilfsfunktionen aufrufen um eine Datenstruktur aufzubauen. Da kann sich das dann schnell negativ auf die Code-Grösse auswirken.)

Ja, da hast du recht. Real-existierende Software kann echt ne Bitch sein - warum wundert es mich nicht, dass es auch hier wieder einige Sonderfälle geben kann, die einem eventuell einen Strich durch die Rechnung machen?

Ich habe ja eigentlich die Hoffnung, dass der Destruktor eines Objekts, von dem "gemoved" wurde in den meisten Fällen einen leeren Branch nimmt, der Optimizer das auch erkennen kann und letztendlich diesen leeren Branch in reines Wohlgefallen "inlined". Aber man weiss nie, bevor man sich nicht den generierten Code angesehen hat. Danke für den Hinweis. Es ist völlig klar, dass der Destruktor aufgerufen werden muss (zumindest "as-if"), aber ich hatte das hierbei tatsächlich nicht auf dem Schirm.

Es ist völlig klar, dass der Destruktor aufgerufen werden muss (zumindest "as-if"), aber ich hatte das hierbei tatsächlich nicht auf dem Schirm.

Naja, es ist abhängig von der Calling-Convention wer den Dtor aufruft. Bei MSVC macht es die aufgerufene Funktion, bei GCC macht es der Aufrufer. (Was GCC übrigens auch dazu zwingt das Objekt im Speicher zu übergeben - auch wenn es klein genug dafür wäre in Registern übergeben zu werden.)

C++

struct Foo {
    Foo(int f) : f{f} {}
    ~Foo();
    int f;
};

void fun(Foo f);

void test() {
    fun(42);
}

MSVC

void test(void) PROC ; test, COMDAT
  mov ecx, 42 ; 0000002aH
  jmp void fun(Foo) ; fun
void test(void) ENDP ; test

GCC

test():
  push rbx
  sub rsp, 16
  lea rdi, [rsp+12]
  mov DWORD PTR [rsp+12], 42
  call fun(Foo)
  lea rdi, [rsp+12]
  call Foo::~Foo() [complete object destructor]
  add rsp, 16
  pop rbx
  ret
  mov rbx, rax
  jmp .L2
test() [clone .cold]:
.L2:
  lea rdi, [rsp+12]
  call Foo::~Foo() [complete object destructor]
  mov rdi, rbx
  call _Unwind_Resume

@Finnegan sagte in Member im Konstruktor per Move oder Copy initialisieren?:

Es ist völlig klar, dass der Destruktor aufgerufen werden muss (zumindest "as-if"), aber ich hatte das hierbei tatsächlich nicht auf dem Schirm.

Naja, es ist abhängig von der Calling-Convention wer den Dtor aufruft. Bei MSVC macht es die aufgerufene Funktion, bei GCC macht es der Aufrufer. (Was GCC übrigens auch dazu zwingt das Objekt im Speicher zu übergeben - auch wenn es klein genug dafür wäre in Registern übergeben zu werden.)

DAS war mir tatsächlich völlig unbekannt. Meine Kenntnis von Calling Conventions beschränkt sich nur darauf wie Argumente übergeben werden und wer den Stack aufräumt. Destruktoren oder gar Dinge wie Exception Handling gehören nicht dazu. Danke für den Hinweis

Meine Kenntnis von Calling Conventions beschränkt sich nur darauf wie Argumente übergeben werden

Was ja auch davon beeinflusst wird. Bei GCC, wenn so ein kleines Objekt keinen Dtor hat, dann wird es in Registern übergeben. Wenn es allerdings einen Dtor hat, dann muss es im Speicher übergeben werden. Weil der Aufrufer ja die Änderungen im Objekt sehen muss, damit er es korrekt zerstören kann.

Und was Optimierungen angeht: MSVC kann dadurch auch oft besser optimieren. Wenn ein Objekt immer "konsumiert" wird und der Dtor daher nichts tun würde, dann kann MSVC den manchmal wirklich wegoptimieren. z.B.:

#include <string>

struct Foo {
    Foo(std::string s);
    std::string s;
};

Foo::Foo(std::string s) : s(std::move(s)) {}

=>

s$GSCopy$ = 0
this$GSCopy$ = 0
this$ = 32
s$ = 40
Foo::Foo(std::basic_string<char,std::char_traits<char>,std::allocator<char> >) PROC ; Foo::Foo, COMDAT
$LN60:
  sub rsp, 24
  xor eax, eax
  mov QWORD PTR this$GSCopy$[rsp], rcx
  xorps xmm0, xmm0
  mov QWORD PTR s$GSCopy$[rsp], rdx
  movups XMMWORD PTR [rcx], xmm0
  mov QWORD PTR [rcx+16], rax
  mov QWORD PTR [rcx+24], rax
  movups xmm0, XMMWORD PTR [rdx]
  movups XMMWORD PTR [rcx], xmm0
  movups xmm1, XMMWORD PTR [rdx+16]
  movups XMMWORD PTR [rcx+16], xmm1
  mov QWORD PTR [rdx+24], 15
  mov QWORD PTR [rdx+16], rax
  mov BYTE PTR [rdx], al
  mov rax, rcx
  mov QWORD PTR [rdx+24], 15
  add rsp, 24
  ret 0
Foo::Foo(std::basic_string<char,std::char_traits<char>,std::allocator<char> >) ENDP ; Foo::Foo

Ist jetzt nicht super übersichtlich, aber man kann denke ich gut sehen dass hier keine Operation zum Freigeben von Speicher vorhanden ist - und auch kein "non-inline" Funktionsaufruf der das indirekt machen könnte. D.h. der std::string Dtor wurde erfolgreich wegoptimiert. Das coole dabei ist, dass dazu kein Inlining von Foo::Foo selbst erforderlich ist - es muss nur der Code der von Foo::Foo aufgerufen wird inlined werden.

Bei GCC und Clang wäre dagegen erforderlich dass Foo::Foo selbst inline in den Aufrufer erweitert wird. Allerdings habe ich mit GCC/Clang noch kein nicht-triviales Beispiel zusammengebracht wo sie da auch wirklich den Dtor wegoptimieren würden. Selbst bei dem einfachen Beispiel mit einem einzigen std::string generieren GCC und Clang Code für den Aufruf des Dtor.

Ich frage mich ob diese Konvention von GCC an anderer Stelle irgendwelche Vorteile hat oder ob die einfach nur historisch gewachsen ist und man jetzt mit der Philosophie des über lange Zeit stabilen ABI festgenagelt ist. Mir persönlich wäre das zumindest nicht wichtig - ich gehe ohnehin immer davon aus, dass ich gerade für C++ auch alle Bibliotheken mit dem selben Compiler und den selben Flags kompilieren muss. Meiner Erfahrung nach ändert sich da gerade mit MSVC öfter mal was. Wenn ich Kompatibiliät will, baue ich ein C-Interface dazu (z.B. "Hourglass-Style": C++ Lib <-> C API <-> C++ Header). Aber ich ich entwickle auch meist an in sich abgeschlossenen Projekten außerhalb der Linux-Paketmanager, wo alle Libs mit dabei sind.

Danke nochmal, wieder was gelernt