Точный момент «возврата» в C++ - функции

Из-за Оптимизация возвращаемого значения (RVO) деструктор для std::string res в make_string_ok не может быть вызван. Объект string может быть создан на стороне вызывающей стороны, и функция может только инициализировать значение.

Код будет эквивалентен:

void make_string_ok(std::string& res){
    Writer w(res);
}

int main() {
    std::string res("A");
    make_string_ok(res);
}

Поэтому возвращаемое значение должно быть «AB».

Во втором примере RVO не применяется, и значение будет скопировано в возвращаемое значение точно после вызова return, а деструктор Writer будет запущен на res.first после того, как произойдет копирование.

6.6 Jump statements

On exit from a scope (however accomplished), destructors (12.4) are called for all constructed objects with automatic storage duration (3.7.2) (named objects or temporaries) that are declared in that scope, in the reverse order of their declaration. Transfer out of a loop, out of a block, or back past an initialized variable with automatic storage duration involves the destruction of variables with automatic storage duration that are in scope at the point transferred from...

...

6.6.3 The Return Statement

The copy-initialization of the returned entity is sequenced before the destruction of temporaries at the end of the full-expression established by the operand of the return statement, which, in turn, is sequenced before the destruction of local variables (6.6) of the block enclosing the return statement.

...

12.8 Copying and moving class objects

31 When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move 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.(123) This elision of copy/move operations, called copy elision, 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 (other than a function or catch-clause parameter) with the same cvunqualified type as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value

123) Because only one object is destroyed instead of two, and one copy/move constructor is not executed, there is still one object destroyed for each one constructed.

В C++ есть концепция под названием elision.

Elision берет два, казалось бы, разных объекта и объединяет их идентичность и время жизни.

До C++ 17 могло произойти исключение:

1. Когда у вас есть переменная без параметров Foo f; в функции, которая вернула Foo, а оператором возврата был простой return f;.

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

В C++ 17 все (почти?) Случаи # 2 исключены новыми правилами prvalue; elision больше не происходит, потому что то, что использовалось для создания временного объекта, больше не выполняется. Вместо этого конструкция «временного» напрямую привязана к постоянному объекту размещения.

Теперь исключение не всегда возможно, учитывая ABI, в который компилируется компилятор. Два распространенных случая, когда это возможно, известны как оптимизация возвращаемого значения и оптимизация именованного возвращаемого значения.

RVO обстоит так:

Foo func() {
  return Foo(7);
}
Foo foo = func();

где у нас есть возвращаемое значение Foo(7), которое опускается в возвращаемое значение, которое затем опускается во внешнюю переменную foo. То, что кажется 3 объектами (возвращаемое значение foo(), значение в строке return и Foo foo), на самом деле равно 1 во время выполнения.

До C++ 17 здесь должны существовать конструкторы копирования / перемещения, и исключение не является обязательным; в C++ 17 из-за новых правил prvalue конструктор копирования / перемещения не требуется, и для компилятора нет опции, здесь должно быть 1 значение.

Другой известный случай - оптимизация возвращаемого значения, NRVO. Это случай (1) исключения, описанный выше.

Foo func() {
  Foo local;
  return local;
}
Foo foo = func();

опять же, elision может объединить время жизни и идентичность Foo local, возвращаемое значение из func и Foo foo вне func.

Даже C++ 17, второе слияние (между возвращаемым значением func и Foo foo) не является необязательным (и технически prvalue, возвращаемое из func, никогда не является объектом, а просто выражением, которое затем связывается для построения Foo foo), но первое остается необязательным, и требует существования конструктора перемещения или копирования.

Исключение - это правило, которое может иметь место, даже если устранение этих копий, разрушений и построений будет иметь заметные побочные эффекты; это не оптимизация "как если бы". Напротив, это небольшое отличие от того, что наивный человек может подумать о коде C++. Называть это «оптимизацией» более чем неправильно.

Тот факт, что это необязательно, и что тонкие вещи могут его сломать, является проблемой.

Foo func(bool b) {
  Foo long_lived;
  long_lived.futz();
  if (b)
  {
    Foo short_lived;
    return short_lived;
  }
  return long_lived;
}

в приведенном выше случае, хотя компилятор может исключать и Foo long_lived, и Foo short_lived, проблемы реализации делают это в принципе невозможным, поскольку оба объекта не могут объединить время жизни обоих с возвращаемым значением func; исключение short_lived и long_lived вместе незаконно, и их время жизни перекрывается.

Вы все еще можете сделать это как если бы, но только если вы можете изучить и понять все побочные эффекты деструкторов, конструкторов и .futz().

Это RVO (+ возврат копии как временной, которая затуманивает изображение), одна из оптимизаций, позволяющих изменять видимое поведение:

10.9.5 Копирование / перемещение элизии(акценты мои):

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the constructor selected for the copy/move operation and/or the destructor for the object have side effects**. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object.

This elision of copy/move operations, called copy elision, 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 (other than a function parameter or a variable introduced by the exception-declaration of a handler) with the same type (ignoring cv-qualification) as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function call's return object
• [...]

В зависимости от того, применяется ли это, вся ваша посылка ошибается. На 1. вызывается c'tor для res, но объект может находиться внутри make_string_ok или снаружи.

Дело 1.

Пункты 2 и 3 могут и не произойти, но это побочный момент. Мишень получила побочные эффекты Writers, пораженных дтором, находилась за пределами make_string_ok. Это оказалось временным, созданным с помощью make_string_ok в контексте оценки operator<<(ostream, std::string). Компилятор создал временное значение, а затем выполнил функцию. Это важно, потому что временное существует вне его, поэтому цель для Writer не является локальной для make_string_ok, а для operator<<.

Случай 2.

Между тем, ваш второй пример не соответствует критерию (как и те, которые были опущены для краткости), потому что типы разные. Так умирает писатель. Он бы даже умер, если бы был частью pair. Итак, здесь копия res.first возвращается как временный объект, а затем dtor Writer воздействует на исходный res.first, который вот-вот умрет сам.

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

В конце концов, это сводится к RVO, потому что объект Writer работает либо на внешнем объекте, либо на локальном, в зависимости от того, применяется оптимизация или нет.

Предписывает ли стандарт, какое значение следует возвращать в приведенных выше примерах, или оно не указано?

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

Случай для этого стал обязательным в C++ 17, но не в вашем. Обязательный - это когда возвращаемое значение является безымянным временным.