|
Boost : |
Subject: Re: [boost] [system] Boost.Timer replacement
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-09-19 16:39:30
Beman Dawes wrote:
>
> http://beman.github.com/timer/ documents a useful replacement
> for Boost.Timer. The full library has been in the sandbox for
> years, but current development is on GitHub.
You use "_t" for a typedef and a struct. Odd.
Why doesn't times() return a times_t? I realize times_t comprises three 64b values, but do you suppose that function will be called in high performance contexts in which returning 192 bits would be problematic?
I may be unobservant, but this is the first time I've noticed a function taking *and* returning a system::error_code &. Is that beneficial? (If that's an idiom you'd encourage, it should be documented in Boost.System.) Changing the one-argument times() to return a times_t would mean this one, too, should return a times_t, but in the case of error, would it be a copy of an uninitialized instance? Maybe the times_t & argument isn't so bad. :)
timer::stop() is inconsistent. If times() and timer::elapsed() take a times_t & argument, then so should timer::stop().
s/stopped/is_stopped/
I dislike the idea of relying on a destructor to report timing information as you've done in run_timer. The no-throw demands of a destructor make I/O questionable since there is no means to report failure. I realize that there is a report() member function that can be called separately, but using the destructor just seems too odd.
"run_timer" doesn't indicating the principle feature: reporting. You might call it "reporting_timer" or "reportable_timer"?
"report" does not imply a call to stop().
Because of all of those strikes against run_timer, I'd prefer something like this:
class timer
{
public:
// as before
void
report(int _places = 2); // writes to std::cout
void
report(int _places, std::ostream & _stream);
void
report(std::string const & _format, int _places = 2);
void
report(std::string const & _format, int _places,
std::ostream & _stream);
};
Those member functions would capture a snapshot of the elapsed time and report it. (That means the I/O would affect further timing values; an accumulated elapsed time and a current start time could be used to ignore the time required for I/O.) A call to stop() followed by a call to report() would be needed to report the elapsed time.
It still might be useful to provide an RAII class to ensure a timer stops at the end of a scope:
timer t;
{
stopper _(t);
// do stuff
}
_____
Rob Stewart robert.stewart_at_[hidden]
Software Engineer using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP http://www.sig.com
________________________________
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk