Re: [boost] Low-level precision timer proposal

From: Philippe Vaucher (philippe.vaucher_at_[hidden])
Date: 2006-07-14 03:58:40

> I guess the whole component has to go through a fast track review, at
> least

Hum, ok.

At a first glance there are a couple of points which perplex me, for
> instance the auto_start/manual_start option.

Well it thought it was pretty obvious, if you want the timer to start
immediatly when it is created of if you want to manually start it with
tmr.start(). To be honest I just took the draft design that was on the wiki
and on vault (from Jeff iirc).

Also, wouldn't an std::clock() based Clock be worth having anyway?

Why not, will try to add one.

AFAICS, only a Win32 Clock is provided.

No no no, this new timer class is meant to be used along with
boost::posix_time::microsec_clock or boost::posix_time::second_clock. The
QueryPerformanecCounter or timeGetTime() implementations are just to give
the user more choices.

However for those implementation(s) one might use (guess what?)
> qpc_clock.

I think 99% of the people will use boost::microsec_timer which is just a
typedef for boost::timer<boost::posix_time::microsec_clock,
boost::posix_time::ptime>. Maybe there's something I didn't understand there
:)

It would also be useful to make a quick comparison with an
> implementation based on GetProcessTimes(), if this hasn't already been
> discussed.

This wasn't discussed but I think it's mainly because this api never seems
to be used for timing stuffs, it's usually GetTickCount(),
QueryPerformanceCounter() or timeGetTime().
IIRC, boost::posix_time:microsec_clock uses GetSystemTime()...

Anyway, I'll try to do a clock() based timer and give a go at
GetProcessTimes().

I'll propose the whole for a fast track review once I'm done with the
documentation and everything, so you think I'd not care about where this
timer class should be now (date_time or timer) and let the review decide it
?

Philippe