Правила доступа к конструктору

Question

Если я скомпилирую (под G ++) и запустив следующий код, он напечатает «Foo :: Foo (int)». Однако после того, как частные конструкторы экземпляров и операторы присваивания закрыты, он не может скомпилироваться со следующей ошибкой: «error:« Foo :: Foo (const Foo &) «является приватным». Как он нуждается в конструкторе копирования, если он вызывает стандартный конструктор во время выполнения?

#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

Конструктор копирования используется здесь:

Foo f = Foo(3); 

Это эквивалентно:

Foo f(Foo(3)); 

где первый набор скобок повторно вызов конструктора копирования. Вы можете избежать этого, говоря:

Foo f(3); 

Обратите внимание, что компилятор может выбрать оптимизировать на вызов конструктора копирования, но конструктор копирования должен еще быть доступен (т.е. не частный). Стандарт C++ специально позволяет эту оптимизацию (см. Раздел 12.8/15), независимо от реализации на самом деле реализации конструктора копирования.

Answer 2

Что вы видите, это результат разрешенной стандартной оптимизацией, когда компилятор избегает создания временного. Компилятору разрешено заменять конструкцию и назначение простой конструкцией даже при наличии побочных эффектов (например, IO в вашем примере).

Но факт, если программа плохо сформирована или нет, не должна зависеть от ситуации, когда компилятор делает эту оптимизацию или нет. Вот почему

Foo f = Foo(3); 

Требуется копировальный аппарат. И

Foo f(3); 

нет. Хотя это, вероятно, приведет к тому же двоичному коду.

Цитата 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

Смотрите также "Оптимизация возвращаемого значения".