Konstruktor Zugriffsregeln

Question

Wenn ich kompilieren (unter G ++) und den folgenden Code ausführen, druckt es "Foo :: Foo (int)". Nachdem jedoch der Kopierkonstruktor und die Zuweisungsoperatoren privat gemacht wurden, kann die Datei nicht mit dem folgenden Fehler kompiliert werden: "Fehler: 'Foo :: Foo (const Foo &)' ist privat". Wie kommt es, dass es einen Kopierkonstruktor benötigt, wenn er zur Laufzeit nur den Standardkonstruktor aufruft?

#include <iostream> 

using namespace std; 

struct Foo { 
    Foo(int x) { 
     cout << __PRETTY_FUNCTION__ << endl; 
    } 


    Foo(const Foo& f) { 
     cout << __PRETTY_FUNCTION__ << endl; 
    } 

    Foo& operator=(const Foo& f) { 
     cout << __PRETTY_FUNCTION__ << endl; 
     return *this; 
    } 
}; 

int main() { 
    Foo f = Foo(3); 
} 

Answer 1

Der Copy-Konstruktor wird hier verwendet:

Foo f = Foo(3); 

Dies entspricht:

Foo f(Foo(3)); 

wo der erste Satz von Pars eine Wieder ein Aufruf an die Copykonstruktor. Sie können dies vermeiden, indem er sagte:

Foo f(3); 

Beachten Sie, dass der Compiler den Copykonstruktor Aufruf optimieren weg, aber der Copykonstruktor muss noch zur Verfügung stehen (das heißt nicht privat) kann wählen. Der C++ - Standard ermöglicht diese Optimierung (siehe Abschnitt 12.8/15), unabhängig davon, was eine Implementierung des Kopierkonstruktors tatsächlich tut.

Answer 2

Was Sie sehen, ist ein Ergebnis der von Standard-Optimierung erlaubt, wenn Compiler die Erstellung von temporären vermeidet. Der Compiler darf die Konstruktion und die Zuweisung durch einfache Konstruktion ersetzen, selbst bei Vorhandensein von Nebeneffekten (wie IO in Ihrem Beispiel).

Aber Tatsache, wenn Programm ist schlecht oder nicht sollte nicht abhängig von der Situation, wenn Compiler macht diese Optimierung oder nicht. Deshalb

Foo f = Foo(3); 

erfordert Kopie Konstruktor. Und

Foo f(3); 

nicht. Obwohl es wahrscheinlich zu demselben Binärcode führen wird.

Zitat von 12.8.15

When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if the copy constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization.111) This elision of copy operations is permitted in the following circumstances (which may be combined to eliminate multiple copies):

— in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object with the same cv-unqualified type as the function return type, the copy operation can be omitted by constructing the automatic object directly into the function’s return value

— when a temporary class object that has not been bound to a reference (12.2) would be copied to a class object with the same cv-unqualified type, the copy operation can be omitted by constructing the temporary object directly into the target of the omitted copy

Siehe "Return Wertoptimierung" auch.