Каково объяснение исключений временного увеличения времени жизни объекта при привязке к ссылке?

Как и многие вещи в C и C ++, я думаю, что это сводится к тому, что можно разумно (и эффективно) реализовать.

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

  struct S {
    int mi;
    const std::pair<int,int>& mp;
  };

  // Case 1:
  std::pair<int,int> tmp{ 2, 3 };
  S a { 1, tmp };

Компилятор может легко продлить жизнь временного tmp на достаточно долгий срок, чтобы поддерживать «S» действительным, потому что мы знаем, что «S» будет уничтожен до завершения функции.

Но в случае "нового S" это не работает:

  struct S {
    int mi;
    const std::pair<int,int>& mp;
  };

  // Case 2:
  std::pair<int,int> tmp{ 2, 3 };
  // Whoops, this heap object will outlive the stack-allocated
  // temporary!
  S* p = new S{ 1, tmp };

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

   // Case 2a -- compiler tries to be clever?
   // Note that the compiler won't actually do this.
   std::pair<int,int> tmp = new std::pair<int,int>{ 2, 3 };
   S* p = new S{ 1, tmp };

Но тогда соответствующему delete p потребуется освободить эту кучу памяти! Это полностью противоречит поведению ссылок и нарушит все, что использует обычную семантику ссылок:

  // No way to implement this that satisfies case 2a but doesn't
  // break normal reference semantics.
  delete p;

Итак, ответ на ваш вопрос: правила определены таким образом, потому что это своего рода единственное практическое решение с учетом семантики C ++ в отношении времени жизни стека, кучи и объектов.

ПРЕДУПРЕЖДЕНИЕ: @Potatoswatter отмечает ниже, что это, похоже, не реализовано последовательно во всех компиляторах C ++ и, следовательно, в лучшем случае на данный момент не является переносимым. Посмотрите на его пример, как Clang не выполняет то, что, по-видимому, требует стандарт. Он также говорит, что ситуация «может быть более ужасной» - я не знаю точно, что это значит, но похоже, что на практике этот случай в C ++ имеет некоторую неопределенность.

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

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

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

В выражении new точка разрушения не может быть статически определена в точке создания. Это всякий раз, когда встречается delete. Если бы мы хотели, чтобы delete (иногда) уничтожал временное, тогда наша эталонная «двоичная» реализация должна быть более сложной, чем указатель, а не меньше или равно. Иногда ему принадлежат упомянутые данные, а иногда нет. Итак, это указатель плюс bool. А в C ++ вы не платите за то, что не используете.

То же самое и в конструкторе, потому что вы не можете знать, был ли конструктор в new или в стеке. Таким образом, любое продление срока службы не может быть статически понято на рассматриваемой линии.

Как долго вы хотите, чтобы временный объект прослужил? Его нужно где-то разместить.

Его не может быть в куче, потому что он протечет; нет применимого автоматического управления памятью. Он не может быть статичным, потому что их может быть больше одного. Он должен быть в стеке. Затем он длится либо до конца выражения, либо до конца функции.

Другие временные элементы в выражении, возможно связанные с параметрами вызова функции, уничтожаются в конце выражения и сохраняются до конца функции или области «{}», что будет исключением из общих правил. Таким образом, путем дедукции и экстраполяции других случаев, полное выражение является наиболее разумным сроком службы.

Я не уверен, почему вы говорите, что это не проблема:

S a { 1,{2,3} };  // No problem.

Висячая ссылка остается неизменной вне зависимости от того, используете ли вы new.

Инструментирование вашей программы и запуск ее в Clang дает следующие результаты:

#include <iostream>

struct noisy {
    int n;
    ~noisy() { std::cout << "destroy " << n << "\n"; }
};

struct s {
    noisy const & r;
};

int main() {
    std::cout << "create 1 on stack\n";
    s a {noisy{ 1 }};  // Temporary created and destroyed.

    std::cout << "create 2 on heap\n";
    s* p = new s{noisy{ 2 }};  // Creates dangling reference
}

create 1 on stack
destroy 1
create 2 on heap
destroy 2

Объект, привязанный к ссылке на член класса, не имеет расширенного срока службы.

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