The profiler that I am proposing would only measure a code block. This restriction is not too burdensome for my purposes, but I can not speak as to other people's unit tests. What is your view on this, generally and w.r.t to your current specific usage case?
Well, profiling associated to a block covers most case but definitively not all cases. So for other cases, we need to be able to start or stop the profiler for a given counter. Cases where blocks profiling are not enough include : - Removing time elapsed in the user interface (say we display a message box to the user). - Profiling that should start in one function and end in another one. - We might need to stop accumulating before the end of the scope in some cases (for example, before displaying an error to the user). - Some timing might be related to event handling or idle processing. - We might want to deduce the time from an inner block to see the calling overhead. For most flexibility, we need automatic (RAII) and manual profiling (explicit start and stop and increment). Philippe