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
>
>...snip details...
>
> 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()
void cpu_time_reporter::report()
>>> 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:
system/time.hpp
system/process.hpp
system/thread.hpp
system/file.hpp
system/posix_impl/time.hpp
system/win32_impl/time.hpp
....
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
>> 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....
Jeff