From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2003-05-21 03:26:16
On Wednesday 21 May 2003 08:31, Jeff Garland wrote:
> Below is what I a sketch of what I have in mind. Pretty similar to
> the current timer, but using a traits specification to define
> core methods and types.
> Also, it has a total_elapsed duration
> value which means that rollover issues are reduced for clock_t
> type implementations since the total_elapsed is snapped when
> the timer is stopped.
But total_elapsed is only updated when the timer is stop'ed thus
you need to stop so you need to stop and start once before
every wraparound of clock(). Next the total_duration_type can not
be clock_t which would seem the logical choice. I think the specialisation
for using clock() will not be straightforward. BTW the implementation
of clear_elapsed will never work for clock_t, I suggest using the
default-constructor instead for zero-ing the total_elapsed
(but I would not store total_elapsed as I'll explain below).
> template <class timer_traits>
> class timer
> typedef timer_traits traits_type;
> typedef typename timer_traits::time_rep time_rep;
> typedef typename timer_traits::time_duration_type time_duration_type;
> timer ();
I would suggest the construct would also start the timing.
> bool is_running() const;
I would suggest a timer always runs.
In short, I prefer the interface of the (Beman's) timer.hpp as it is now,
very simple but effective.
> With this approach we can create a 'wallclock' timer using one of the clock
> classes from the date_time library (see testTimer.cpp for examples)
> Now we can do interesting things like:
> timer<wallclock_timer_traits> wall_timer;
> timer<clockt_timer_traits> clockt_timer;
This seems like a good idea to me.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk