#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 hinder):
I did think about using some sort of C++ scoping construct as you suggested to ensure that timers were deleted automaticall. I think I wanted to make the minimal change to the Timer API so that all the existing timer usage didn't have to be changed. One thing I'm not sure about: can you be sure of the order in which the destructors are called if you have more than one timedblock in scope? If not, then you would need to have multiple levels of {...} nesting when you have more than one timer, which would be ugly.
What happens to the reference if you return a reference to the string, and the TimerNode object subsequently gets deleted? The string will have been deleted (it was part of the TimerNode object) but the reference will remain. In general, the Carpet timers are used around large chunks of code so they should not be performance critical. However, there are some parts of CarpetLib which I think use the timers which this might not apply to.