这是否会遇到有关对象生命周期的未定义行为？
#include "stdio.h"
class C {
public:
~C() { printf("~C\n"); }
};
int I(const C& c) { printf("I\n"); return 0; }
void V(int i) { printf("V\n"); }
int main() {
V(I(C()));
return 0;
}
看到的输出：
I
V
~C
我所期望的：
I
~C
V
#include "stdio.h"
class C {
public:
~C() { printf("~C\n"); }
};
int I(const C& c) { printf("I\n"); return 0; }
void V(int i) { printf("V\n"); }
int main() {
V(I(C()));
return 0;
}
Seen output:
I
V
~C
what I would have expected:
I
~C
V
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
C()创建一个临时变量，该临时变量持续直到完整表达式完成，并且完整表达式的完成是;< /code>（即分号）。这就是为什么你会看到我认为输出是明确定义的。标准第 §12.2/3 节内容如下：
只是强调一下，在此示例中，临时变量的生命周期与函数
I()的 引用 或 const 引用 参数无关。即使I()的签名是：临时值将持续到完整表达式完成，并且您将看到完全相同相同的输出。
请参阅：http://www.ideone.com/RYWhy
C()creates a temporary which persists till the completion of the full expression, and the completion of the full expression is;(i.e the semicolon). That is why you see that output which is in my opinion is well-defined.Section §12.2/3 from the Standard reads,
Just to emphasize, in this example the lifetime of the temporary has nothing to do with the reference or const reference parameter of function
I(). Even if the signature ofI()is:the temporary would persist till the completion of the full expression and you would see exactly the same output.
See this: http://www.ideone.com/RYWhy
对
V的调用在完整表达式完全求值之前返回。当V返回时，它将打印其内容（从V返回之前有一个序列点）。临时的
C()仅在完整的完整表达式求值后才会被销毁。The call to
Vreturns before the full expression has been completely evaluated. And whenVhas returned, it will have printed its stuff (there is a sequence point before returning fromV).The temporary
C()is only destroyed after the complete full expression has been evaluated.为什么？临时的生命直到完整表达结束为止。
Why? The temporary lives till the end of the full expression.
您看到的行为是标准规定的行为：临时对象在创建它们的完整表达式结束时被销毁。
历史上曾出现过另一种行为（并且在某些编译器中仍然可用）：在块末尾进行销毁。就您而言，这不会产生任何影响，因为它进一步延迟了破坏。
The behavior you are seeing is the one mandated by the standard: temporaries are destroyed at the end of the full expression creating them.
Historically another behavior was seen (and is still available in some compilers): destruction at the end of the block. In your case it wouldn't have made a difference as it delays still further the destruction.