C++: возврат по ссылке и конструкторы копирования

Лучший способ понять копирование в C++ — часто НЕ пытаться создать искусственный пример и инструментировать его — компилятору разрешено как удалять, так и добавлять вызовы конструктора копирования, более или менее по своему усмотрению.

Итог - если вам нужно вернуть значение, верните значение и не беспокойтесь ни о каких "расходах".

Рекомендуемая литература: Effective C++ Скотта. Мейерс. Там вы найдете очень хорошее объяснение этой темы (и многого другого).

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

Если вы возвращаете по ссылке (или указателю) переменную, которая является локальной (построенной в стеке), вы вызываете проблемы, потому что объект уничтожается при возврате, поэтому в результате вы получаете висячую ссылку.

Канонический способ создать объект в функции и вернуть его по значению, например:

MyClass fun() {
    return MyClass(a, b, c);
}

MyClass x = fun();

Если вы используете это, вам не нужно беспокоиться о проблемах владения, оборванных ссылках и т. д. И компилятор, скорее всего, оптимизирует дополнительные вызовы конструктора/деструктора копии, поэтому вам также не нужно беспокоиться о производительности.

Возможен возврат по ссылке объекта, построенного new (т.е. в куче) — этот объект не будет уничтожен при возврате из функции. Однако вы должны где-то позже явно уничтожить его, вызвав delete.

Также технически возможно хранить объект, возвращаемый по значению, в ссылке, например:

MyClass& x = fun();

Однако, AFAIK, особого смысла в этом нет. Тем более, что эту ссылку можно легко передать другим частям программы, которые находятся за пределами текущей области; однако объект, на который ссылается x, является локальным объектом, который будет уничтожен, как только вы покинете текущую область. Таким образом, этот стиль может привести к неприятным ошибкам.

прочитайте об RVO и NRVO (одним словом эти два означают оптимизацию возвращаемого значения и именованный RVO, и методы оптимизации, используемые компилятором для достижения того, чего вы пытаетесь достичь)

вы найдете много тем здесь, в stackoverflow

Если вы создаете такой объект:

MyClass foo(a, b, c);

тогда он будет в стеке в кадре функции. Когда эта функция завершается, ее фрейм выталкивается из стека, и все объекты в этом фрейме уничтожаются. Этого нельзя избежать.

Итак, если вы хотите вернуть объект вызывающей стороне, у вас есть только следующие варианты:

• Возврат по значению — требуется конструктор копирования (но вызов конструктора копирования может быть оптимизирован).
• Верните указатель и убедитесь, что вы либо используете интеллектуальные указатели для работы с ним, либо аккуратно удаляете его самостоятельно, когда закончите с ним.

Попытка создать локальный объект, а затем вернуть ссылку на эту локальную память в вызывающий контекст не является согласованной — вызывающая область не может получить доступ к памяти, которая является локальной для вызываемой области. Эта локальная память действительна только в течение срока действия функции, которой она принадлежит, или, другими словами, пока выполнение остается в этой области. Вы должны понимать это, чтобы программировать на C++.

Возвращать ссылку имеет смысл только в том случае, если вы возвращаете ссылку на уже существующий объект. Наглядный пример: почти каждая функция-член iostream возвращает ссылку на iostream. Сам iostream существует до вызова любой из функций-членов и продолжает существовать после их вызова.

Стандарт допускает «исключение копирования», что означает, что конструктор копирования не нужно вызывать, когда вы возвращаете объект. Это происходит в двух формах: оптимизация возвращаемого значения имени (NRVO) и анонимная оптимизация возвращаемого значения (обычно просто RVO).

Из того, что вы говорите, ваш компилятор реализует RVO, но не NRVO, что означает, что это вероятно несколько более старый компилятор. Большинство современных компиляторов реализуют оба. Несовпадающий dtor в данном случае означает, что это, вероятно, что-то вроде gcc 3.4 или около того — хотя я точно не помню версию, тогда была одна, в которой была подобная ошибка. Конечно, также возможно, что ваша инструментация не совсем правильная, поэтому используется ctor, который вы не инструментировали, и для этого объекта вызывается соответствующий dtor.

В конце концов, вы застряли в одном простом факте: если вам нужно вернуть объект, вам нужно вернуть объект. В частности, ссылка может дать доступ только к (возможно, модифицированной версии) существующего объекта, но этот объект также должен быть создан в какой-то момент. Если вы можете изменить какой-то существующий объект, не вызывая проблем, это прекрасно и хорошо, продолжайте и делайте это. Если вам нужен новый объект, отличный от тех, которые у вас уже есть, сделайте это — предварительное создание объекта и передача ссылки на него может ускорить сам возврат, но в целом не сэкономит время. Создание объекта имеет примерно одинаковую стоимость независимо от того, выполняется ли оно внутри или вне функции. Любой достаточно современный компилятор будет включать RVO, так что вы не будете платить никаких дополнительных затрат за его создание в функции, а затем возвращать его — компилятор просто автоматизирует выделение места для объекта, куда он будет возвращен, и получит функцию создайте его «на месте», где он все еще будет доступен после возврата функции.

По сути, возврат ссылки имеет смысл только в том случае, если объект все еще существует после выхода из метода. Компилятор предупредит вас, если вы вернете ссылку на что-то, что уничтожается.

Возврат ссылки, а не объекта по значению, позволяет сэкономить на копировании объекта, что может иметь большое значение.

Ссылки безопаснее, чем указатели, потому что они имеют другую симантику, но за кулисами они являются указателями.

Одно из возможных решений, в зависимости от вашего варианта использования, состоит в том, чтобы создать объект по умолчанию вне функции, взять in ссылку на него и инициализировать указанный объект внутри функции, например:

void initFoo(Foo& foo) 
{
  foo.setN(3);
  foo.setBar("bar");
  // ... etc ...
}

int main() 
{
  Foo foo;
  initFoo(foo);

  return 0;
}

Теперь это, конечно, не работает, если невозможно (или не имеет смысла) создать по умолчанию объект Foo, а затем инициализировать его позже. Если это так, то ваш единственный реальный способ избежать создания копии — вернуть указатель на объект, размещенный в куче.

Но затем подумайте, почему вы вообще пытаетесь избежать копирования. Действительно ли «затраты» на создание копии влияют на вашу программу или это случай преждевременной оптимизации?

Вы застряли либо:

1) возврат указателя

MyClass* func(){ //некоторые вещи возвращают новый MyClass(a,b,c); }

2) возврат копии объекта MyClass func(){ return MyClass(a,b,c); }

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

Не прямой ответ, но жизнеспособное предложение: вы также можете вернуть указатель, завернутый в auto_ptr или smart_ptr. Тогда вы будете контролировать, какие конструкторы и деструкторы вызываются и когда.