问题
According to C++14 [expr.call]/4:
The lifetime of a parameter ends when the function in which it is defined returns.
This seems to imply that a parameter's destructor must run before the code which called the function goes on to use the function's return value.
However, this code shows differently:
#include <iostream>
struct G
{
G(int): moved(0) { std::cout << "G(int)\n"; }
G(G&&): moved(1) { std::cout << "G(G&&)\n"; }
~G() { std::cout << (moved ? "~G(G&&)\n" : "~G()\n"); }
int moved;
};
struct F
{
F(int) { std::cout << "F(int)\n"; }
~F() { std::cout << "~F()\n"; }
};
int func(G gparm)
{
std::cout << "---- In func.\n";
return 0;
}
int main()
{
F v { func(0) };
std::cout << "---- End of main.\n";
return 0;
}
The output for gcc and clang , with -fno-elide-constructors
, is (with my annotations):
G(int) // Temporary used to copy-initialize gparm
G(G&&) // gparm
---- In func.
F(int) // v
~G(G&&) // gparm
~G() // Temporary used to copy-initialize gparm
---- End of main.
~F() // v
So, clearly v
's constructor runs before gparm
's destructor. But in MSVC, gparm
is destroyed before v
's constructor runs.
The same issue can be seen with copy-elision enabled, and/or with func({0})
so that the parameter is direct-initialized. v
is always constructed before gparm
is destructed. I also observed the issue in a longer chain, e.g. F v = f(g(h(i(j())));
did not destroy any of the parameters of f,g,h,i
until after v
was initialized.
This could be a problem in practice, for example if ~G
unlocks a resource and F()
acquires the resource, it would be a deadlock. Or, if ~G
throws, then execution should jump to a catch handler without v
having been initialized.
My question is: does the standard permit both of these orderings? . Is there any more specific definition of the sequencing relationship involving parameter destruction, than just that quote from expr.call/4 which does not use the standard sequencing terms?
回答1:
Actually I can answer my own question... didn't find an answer while searching before writing it, but then searching again afterwards did find an answer (typical huh).
Anyway: this issue is CWG #1880 with the resolution:
Notes from the June, 2014 meeting:
WG decided to make it unspecified whether parameter objects are destroyed immediately following the call or at the end of the full-expression to which the call belongs.
The latest C++17 draft that I have (N4606) has changed the text in [expr.call]/4:
It is implementation-defined whether the lifetime of a parameter ends when the function in which it is defined returns or at the end of the enclosing full-expression.
I guess we should treat this resolution (i.e. "implementation-defined") as applying retroactively , since it was not well specified by published standards.
Note: The definition of full-expression can be found in C++14 [intro.execution]/10:
A full-expression is an expression that is not a subexpression of another expression. [...] If a language construct is defined to produce an implicit call of a function, a use of the language construct is considered to be an expression for the purposes of this definition.
So F v { func(0) };
is the enclosing full-expression for gparm
(even though it's a declaration and not an expression!).
来源:https://stackoverflow.com/questions/39824814/sequencing-of-function-parameter-destruction