Является ли этот код четко определенным, независимо от того, есть ли копия?

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

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

за исключением копии:

[...] реализации разрешается опускать конструкцию копирования / перемещения объекта класса, даже если конструктор, выбранный для операции копирования / перемещения, и / или деструктор для объекта имеют побочные эффекты. [...]

Но правила последовательности по-прежнему должны соблюдаться, и если мы перейдем к черновику стандарта, мы увидим, что знаем, что присваивание выполняется после того, как левый и правый операнды оцениваются из раздела 5.17:

Во всех случаях присваивание выполняется после вычисления значения правого и левого операндов и перед вычислением значения выражения присваивания.

и мы знаем, что тело функции неопределенно упорядочено по отношению к другим вычислениям, которые специально не упорядочены с вызовом функции из раздела 1.9:

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

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

Оценки A и B являются неопределенными последовательностями, когда либо A упорядочивается до B, либо B - до A, но не указано, что именно. [Примечание: оценки с неопределенной последовательностью не могут перекрываться, но любая из них может быть выполнена первой. —В конце примечания]

Нет, не может. Оптимизация не может сломать правильно сформированный код, и этот код правильно сформирован.

РЕДАКТИРОВАТЬ: небольшое обновление. Конечно, мой ответ предполагает, что сам компилятор не содержит ошибок, о чем, конечно же, можно только молиться :)

EDIT2: некоторые люди говорят о побочных эффектах в конструкторах копирования и о том, что они плохие. Конечно, неплохие. Мне кажется, что в C ++ не гарантируется создание известного количества временных объектов. Вам гарантируется, что каждый созданный временный объект будет уничтожен. Хотя оптимизации позволяют уменьшить количество временных объектов, выполняя копирование, им также разрешено увеличивать его! :) Пока ваши побочные эффекты кодируются с учетом этого факта, вы в порядке.

Нет, не могло!

Оптимизация не означает, что вы получаете неопределенное поведение в хорошо написанном (не плохо обусловленном) коде.

Проверьте это исх .:

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

Соответствующая реализация, выполняющая правильно сформированную программу, должна производить такое же наблюдаемое поведение, как одна из возможных последовательностей выполнения соответствующего экземпляра абстрактной машины с той же программой и теми же входными данными. ...

Наблюдаемое поведение абстрактной машины - это последовательность операций чтения и записи в изменчивые данные и вызовов библиотечных функций ввода-вывода. ...

взято из этого ответа.

В этом ответе вы можете увидеть случай, когда copy-elision может давать другой результат!

Единственное, что разрешено "нарушить" copy elision, - это когда у вас есть побочные эффекты в вашем конструкторе копирования. Это не проблема, потому что конструкторы копирования всегда не должны иметь побочных эффектов.

Для иллюстрации вот конструктор копирования с побочными эффектами. Поведение этой программы действительно зависит от оптимизаций компилятора, то есть от того, действительно ли сделана копия или нет:

#include <iostream>

int global = 0;

struct Test
{
    int x;
    int y;

    Test() : x(0), y(0) {}

    Test(Test const& other) :
        x(other.x),
        y(other.y)
    {
        global = 1; // side effect in a copy constructor, very bad!
    }
};

Test func(const Test& in)
{
    Test out;
    out.x=in.y;
    out.y=in.x;
    return out;
}

int main()
{
    Test test;
    std::cout << "x: " << test.x << ", y: " << test.y << "\n";
    test=func(test);
    std::cout << "x: " << test.x << ", y: " << test.y << "\n";
    std::cout << global << "\n"; // output depends on optimisation
}

Показанный вами код не имеет таких побочных эффектов, а поведение вашей программы четко определено.

Elision - это слияние сущностей и идентичностей объектов.

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

По сути, Elision ездит на работу. (Если объекты A и B исключены вместе, а объекты B и C исключены вместе, то фактически A и C удаляются вместе).

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

Этот конструктор внешней переменной располагается после тела func и, следовательно, после вызова func. Так что это не могло произойти до вызова func.

Здесь приведен пример случая, когда мы назвали переменную до ее создания, и передать его func, затем инициализировать переменную возвращаемым значением func. Похоже, что компилятор решил не исключать в этом случае, но, как показано ниже в комментариях, id действительно сделал: мой вызов UB скрыл исключение. (свертка была попыткой помешать компилятору предварительно вычислить значения test.x и test.y).