From: Jeff Garland (jeff_at_[hidden])
Date: 2006-06-25 17:44:39
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.
>> 3) I see some major overlap in your plans with Boost.Process. You
>> are providing what amounts to a a simplified form of what I what
> The interface for my example is one line of code:
> boost::system::cpu_time_reporter tr;
> So while it might be implemented using Julio's process design,
> cpu_time_reporter provides a completely packaged solution. Unless I
> missed something (always possible!), I don't see process as providing
> the same thing.
No it doesn't. Are you saying the process_exec isn't going to be part of the
system api? That's the part the overlaps..
>> 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()
>>> My plan is to submit the CPU timer stuff as part of a Boost.System
>>> library, which packages small operating system dependent
>>> components together for convenience.
>> For the moment, I mostly see things that overlap other current
>> library efforts -- error codes excepted. That said, I really applaud
>> the effort. In my view, Boost has being a piecemeal design OS api
>> portability -- as an example, we have 3 libraries that retrieve clock
>> time values from the system clock (thread, date-time, timer).
> timer should be retired. threads should use date-time facilities. If
> cpu_timer is better implemented by calling date-time or process, that is
> OK with me, but I really like the simple cpu_timer and cpu_time_reporter
> interfaces. A user should not have to master a complex library just to
> write what amounts to one line of code.
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:
Of course, that make cpu timer somewhat questionable as an element of the
system library -- it would need to be an add-on.
>> 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
> 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....
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk