On Wednesday 21 May 2003 14:39, Jeff Garland wrote:
> Did you look at the attached test program which had this traits adapter?
nope. I must have missed that although I check all attachments (I think)
> static time_duration_type make_time_duration(time_rep start, time_rep end)
> {
> assert(CLOCKS_PER_SEC == time_duration_type::rep_type::res_adjust());
> return time_duration_type(0,0,0, end - start);
> }
I think the traits are too dependent on the time_duration_type coming from
the date-time library. It should be possible to reset the elapsed time using
a default-constructed time_duration_type and set the a time_duration_type
using an operator= instead of the constructor with 4 arguments.
But these are details that can be solved when making real-life
specialisations. So back to the overall strategy :
I think it's a good idea to provide a templated timer that can be
specialised for timing cpu-time or wall-clock time. The template-argument
however should be allowed to have different implementations
on different platforms. E.g. as I mentioned before, the clock()
function wraps around too quick. On 32-bit POSIX systems
(CLOCKS_PER_SEC must be 1M) you have a wraparound every 72 minutes.
So I would for instance implement the cpu-timer using getrusage (on linux) etc.
> That assumption really limits the use of the timer. For example,
> you can't use it in a user interface where a start/stop button
> can be controlled by a user to measure the total elapsed time on
> a task that might be interupted. For program timing there might be
> sections of the program execution I would like to ignore. This is
> not possible without a stop function.
OK, agreed.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
