Jeff Garland wrote:
Beman Dawes wrote:
Jeff Garland wrote:
Beman Dawes wrote: 2) get_process_times compile fails on Linux -- fairly obvious issue here...I'm guessing you are testing on Windows :-) Fixed. Vault .zip updated.
Yes, I was testing mostly on Windows. I tested on a Mac, and then forgot to retest after making some changes. It is working now on my Mac, but I don't have a running Linux system to test on.
I've posted a couple other changes in a new thread.
Thanks! I've applied those fixes. ... Are you saying the process_exec isn't going to be part of the
system api? That's the part the overlaps..
process_exec? That wasn't supposed to be included in the .zip file. It was an experiment that failed. Sorry it slipped in.
4) Eating exceptions:
I don't like this code. I've been burned a few times by code that does eats exceptions.... Throwing exceptions from destructors is usually considered a no-no. Note that it is possible to use explicit calls to stop() etc., and detect that an error occurred.
I guess someone could make a case that exceptions should be thrown except in the destructor. I'll have to think about that.
Well, you're assuming that report will be called in a destructor. If it isn't and some sort of exception is thrown then the application can't handle it because you've eaten it. You could always have 2 versions:
void cpu_time_reporter::report_no_exceptions() throws() void cpu_time_reporter::report()
Yes, that's the idea, although the actual implementation might differ. For the functions that where changed to possibly throw, there should also be non-throwing versions available. Good. That will be another use case for system_error etc.
...
I guess I should have made it clear that I like the cpu timer interface -- it's certainly valuable. And I totally agree that we want simple things to be simple. I'm mostly commenting on the broader purpose of System and what should be contained in it. See below for more...
Well, the error encapsulation really doesn't fit in any other single library, so at that point the camel's nose is under the tent and so we might as well acknowledge "system" as a small library and see what else fits into it, I think.
Yep. Again my thought is that it would be the collector for an OS portability layer. So you might have something like:
system/time.hpp system/process.hpp system/thread.hpp system/file.hpp system/posix_impl/time.hpp system/win32_impl/time.hpp ....
Interesting. I want to come back to this in another post. The question is one of degree. I think that is important, but don't have time to delve into it now.
Of course, that make cpu timer somewhat questionable as an element of the system library -- it would need to be an add-on.
Just because a library is primarily aimed as OS portability, that doesn't mean it can't have convenience functions or classes layered on top of the lower-level stuff.
By returning a microseconds from functions like wall() the user can use the date-time streaming operators directly including the output formatting strings associated with time duration. I believe this would also eliminate the the double-based precision issues in the I/O code. That sounds like an improved way to implement cpu_time_reporter, and offers other user benefits too, I would guess.
I think so.
One problem I see is that date-time doesn't have an easy way to do set-precision on i/o...something it probably needs. My guess is that control over precision is something users really will want.
It hasn't come up yet, but I've been expecting it to....
I really think that being able to control precision is important. For many platforms and applications, anything more that one or two decimal places is misleading, unnecessary, and unwanted. OTOH, some platforms and/or applications may benefit from more decimal places, and I'd like to allow that sort of control if the user desires. Thanks, --Beman