#477: Carpet commit f33caf3aba96 (hg) breaks timer output in CCTK_Terminate ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: eschnett Type: defect | Status: review Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by rhaas):
Apparently the order of destruction is the reverse order of construction (which is useful to know): http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.2 http://stackoverflow.com/questions/2254263/order-of-member-constructor- and-destructor-calls or formally: http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2011/n3242.pdf (stackoverflow has section numbers) so multiple timers are fine it seems.
As for references: (as I understand it) if getName() returned a reference and a user assigned this to a reference and then deleted the owning TimerNode then the reference would be a dangling pointer (essentially). Something like {{{ char *a = new char('a'); char &b = *a; delete a; std::cout << b << std::endl; }}} will segfault (or not...).
If on the other hand you assign to a string then copying takes place (even if a reference is returned) and everything is fine. In the case where you return a string object but the user assigns to a reference I think you end up with an invalid reference right away, and g++ will not even compile it:
{{{ #include <string> #include <iostream>
std::string blurp("blah"); std::string blah() { return blurp; }
int main() { std::string &foo = blah(); return 0; } }}}
So my approach would be that the segfault can only occur the user assign to a reference in which case the user knows what she is doing and we supply her with sufficient rope to hang herself if she so chooses :-)
But as you say, it very likely makes no difference at all unless one times very short, local functions.