[boost] Re: timer classes

From: Ed Brey (brey_at_[hidden])
Date: 1999-07-01 14:22:09

Email seemed somewhat boring, until Beman Dawes wrote:
>
>>- Hiding the implementation details for timer provides a bad tradeoff:
>>it requires an otherwise unnecessary heap allocation for each instantiation
>>of a timer.  It would be better to byte the bullet and put clock_t into
>>the timer class.
>
>I really do want to divorce timer from its implementation. Rationale:
>
>     * On some systems it won't be possible to use the C clock
>functions at all, yet it will be possible to implement timer using
>native functions.

It is possible to get this flexiblity without sacrificing (i.e. adding)
the level of indirection that the reference/pointer causes.  Something
like this works well:

// timer.h
template<class ClockImpl>
class basic_timer {
public:
...  // Inlined member functions
private:
        ClockImpl::clock_type start_time;
};

// cclockimpl.h
#include "timer.h"

class c_clock_impl
{
public:
        typedef clock_t clock_type;
        static const clock_type clocks_per_sec = CLOCKS_PER_SEC;
        static const clock_type max_clock = ???;
        static clock_type now() {return clock();}
};

typedef basic_timer<c_clock_impl> timer;  // Maybe should be c_timer.

This will result in much smaller and faster code: no heap use, no extra
indirection, trivial function calls inlined.

>     * Exposing clock_t means including <ctime> which includes two
>macros.  I dislike that.

Me too.  However, I dislike the performance hit on something that is
often performance critical even more.  Furthermore, given the complaints
on this server about clock_t, it appears likely that many people will
be replacing the "default" c_clock_impl with better ones for better
performance, and ctime won't need to be included.

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications