c++ - 在 C++ 标准中临时绑定到成员生命周期语句有什么意义？

Question

在这个问题中，用户Happy Mittal引用了 C++03 标准的第 12.2.5 节：临时绑定到构造函数的 ctor-initializer (12.6.2) 中的引用成员，直到构造函数退出。

这怎么可能有用呢？我的意思是一旦构造函数退出临时被破坏，但引用仍然绑定 - 现在到一个已经被破坏的对象。

如果外部对象的整个生命周期仍然存在悬空引用，那么仔细指定临时生命周期有什么意义？这种行为在哪种情况下有用？

score 8 · Accepted Answer

将引用成员绑定到死对象是没有用的，但需要明确的是，绑定到引用时的“正常”临时生命周期延长不适用于这种情况。

它还指定了特别适用于 ctor 初始化程序的临时生命周期扩展：它被扩展到 ctor 的末尾，而不是在 ctor 主体执行之前死亡。这将没有用，除非在“聪明”的类中，其重点是执行 ctor，并且正确地避免了这种类型的 (ab) 使用。

我不知道后者在现实世界中的例子，但它让我感到类似于让析构函数默认不抛出在其生命周期中“聪明”的破坏类以及它们的使用方式。这确实有实际用途，并在讨论如何处理 C++0x 中 dtors 的默认语义时出现。

score 2 · Accepted Answer

在D语言中，构造过程在一定程度上可以自由编写。但是在 C++ 中，构造/初始化顺序是严格规定的。因此，如果类初始化需要一些昂贵的计算，那么像下面这样的代码有时可能是一种不情愿的解决方法。

struct S {
  Args const &r;
  A a;
  B b;
  S( args.... )
    : r( expensive_func( args.... ) ), a( r.for_a ), b( r.for_b ) {}
};

score 1 · Accepted Answer

它对编译器编写者很有用。他们已经有逻辑可以在作用域的末尾销毁绑定的临时对象，构造函数的退出就是这样一个点。使用此规则，编译器也可以重用该点来销毁此类临时文件。

请注意，标准确实应该决定某个生命周期，而唯一合理的一点是在 ctor 初始化列表之后但在 ctor 主体之前。这不是临时对象会被破坏的地方，并且它可能会干扰函数范围try {} catch()块（其中确实包括 ctor 初始化器列表）

3 回答 3