I guess it depends on what you're using the timer for. I really don't mind either way as long as the behaviour is well-documented. When I'm using a "microsecond timer", it is because I want to measure short intervals, not long ones. But perhaps there should be clearer ways of specifying the precision/accuracy/resolution trade-offs desired?
At the moment I think about an api like this : - portable: microsec_timer: documented as most robust timer, not the best resolution one, good enough for 90% of the timings. - portable: second_timer: this one is kindof obvious, no need to describe much - portable: clock_timer: timer based on std::clock, documentation about clock() issue and resolutions - windows: qpc_timer: documented as best resolution, not thread safe & multi core problem. Hability to set a macro that automatically calls SetThreadAffinityMask() - windows: tgt_timer: documented as a good alternative to qpc ( I think tgt > GetSytemTimeAsFileTime ) - To discuss but I may add those timers : - windows: gst_timer: uses GetSystemTimeAsFileTime (actually microsec_clock already uses gst but it may change so why not offer an explicit one). - windows: gtc_timer: uses GetTickCount() - linux: gtod_timer: uses gettimeofday() (actually microsec_clock already uses gtod but it may change so why not offer an explicit one). If you know of other linux timers that'd be worth using please mention them thank you. I think that if each timer type is well documented about resolution, thread safety, multi-core issues and all the others gotcha's those timers are giving us headaches about, then the user can choose the timer he wants and take the risk himself. Of course I think we should suggest the users to use microsec_timer for portable code. I kinda like this approach because the user is free to make his choices and aware of the issues... At the moment I'm not very happy about using QPC for microsec_timer because it looks like the pros (satisfies some people, not the majority?) doesn't outweight the cons (all the issues about QPC). On second thought, apparently Java calls their QPC implementation is called
"nano" instead. Perhaps we could use that terminology as well?
I already thought a bit about this and at start my timers were named nanosec_timer or smth, but then this idea collided with date_time::microsec terminology and I decided to be consistent with other parts of boost. Philippe