Boost logo

Boost :

From: Beman Dawes (beman_at_[hidden])
Date: 1999-07-01 08:12:50


At 10:13 AM 6/30/99 -0500, Ed Brey wrote:

>Email seemed somewhat boring, until Beman Dawes wrote:
>>
>>I would like to get some feedback on two timer and one progress
>>reporting class before going to the trouble of documenting them.
See
>>http://www.boost.org/libs/timer/
>
>There are many good features. Here are some aspects that could use
>improvement, IMHO, however:
>
>- Progress display and timers seem to be unrelated. They shouldn't
>be kept in the same file.

You are right, of course, that logically they are unrelated. The
rationale for combining them was:

   * Avoiding header proliferation.
   * In practice, programs that use progress_display also use
job_timer.

Perhaps timer should be in its own header. It is much more general
that job_timer and progress_display which were originally designed
for console programs only.

>- 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.

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

So while I appreciate the comment, I will keep the implementation
separate unless someone comes up with a killer argument not to.

>- Add a member function or constant to allow programatic access the
>time limit of the implementation before overflow occurs.

Good idea. Hum... How do you implement that using <ctime>? I will
have to ask some C experts, but it looks to me like you just came up
with a hole in the C standard! I have sent a message to the
committees asking for information.

Thanks for the feedback,

--Beman

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

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk