|
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