Размещение новых разрывов, констант и ссылок?

Я считаю, что мотивация состоит в том, чтобы позволить компилятору кэшировать значения объектов const (обратите внимание, что const objects, а не просто ссылки на указатели на константу и ссылку на константу) и адреса референсы ссылок через вызовы неизвестного кода.

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

struct Foo {
    const int & x;
    Foo (int & i) : x(i) {}
};

int i = 1;
Foo f(i);

some_function_in_another_TU(&f);

std::cout << f.x;

В это:

struct Foo {
    const int & x;
    Foo (int & i) : x(i) {}
};

int i = 1;
Foo f(i);

some_function_in_another_TU(&f);

std::cout << i;           // this line is optimized

потому что ссылочный элемент f не может быть переустановлен и, следовательно, должен по-прежнему ссылаться на i. Операция уничтожения и построения нарушает неповторяемость ссылочного члена x.

Эта оптимизация не должна вызывать особых споров: рассмотрим следующий пример, в котором используется объект const, а не объект с const или ссылочным членом:

const int i = 1;
some_function_in_another_TU(&i);
std::cout << i;

Здесь i - константа времени компиляции, some_function_in_another_TU не может корректно уничтожить ее и создать на ее месте другой int с другим значением. Таким образом, компилятору должно быть разрешено генерировать код для std::cout << 1;. Идея состоит в том, что то же самое должно быть верно по аналогии для константных объектов других типов и для ссылок.

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

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

Bar important, relevant;

Foo x(important);  // binds as const-reference

Zoo z(x);  // also binds as const reference

do_stuff(z);

x.~Foo();
::new (&x) Foo(relevant);  // Ouch?

Объект z может разумно ожидать, что его Foo ссылка на член будет постоянной и, таким образом, относится к important. Как сказано в стандарте, разрушение плюс новое построение в последних двух строках «автоматически обновляет все ссылки, чтобы ссылаться на (логически) новый объект», поэтому теперь константная ссылка внутри z изменилась, несмотря на обещание быть постоянным.

Чтобы избежать этого грубого нарушения корректности const, вся реконструкция на месте запрещена.

Оптимизация. Предположим, у меня есть:

struct Foo
{
    int const x;
    Foo( int init ) : x( init ) {}
};

int
main()
{
    Foo a( 42 );
    std::cout << a.x << std::endl;
    new (&a) Foo( 3 );
    std::cout << a.x << std::endl;
    return 0;
}

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

Обратите внимание, что ваш пример на самом деле совсем другой. Член данных имеет тип int const&; это ссылка (а ссылки всегда константы), поэтому компилятор может предположить, что ссылка всегда относится к одному и тому же объекту. (Значение этого объекта может измениться, если сам объект также не является константой.) Однако компилятор не может делать таких предположений о значении объекта, на который он ссылается, поскольку i (в вашем случае) может явно измениться. Именно тот факт, что сама ссылка (как и все ссылки) является неизменной, вызывает здесь неопределенное поведение, а не const, который вы написали.

Если что-то квалифицируется как const, вы не должны его изменять. Продление срока службы - это модификация с серьезными последствиями. (Например, подумайте, есть ли у деструктора побочные эффекты.)