[boost] Re: : [chrono] v0.4.5 Documentation update + warnings +removal +›ug fixes

Subject: [boost] Re: : [chrono] v0.4.5 Documentation update + warnings +removal +›ug fixes
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-08-13 12:50:02

----- Original Message ----- 
From: "Tan, Tom (Shanghai)" <TTan_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 13, 2010 10:25 AM
Subject: Re: [boost] : [chrono] v0.4.5 Documentation update + warnings +removal + bug fixes

> >Date: Tue, 10 Aug 2010 20:00:15 +0200
>>From: "vicente.botet" <vicente.botet_at_[hidden]>
>>Subject: [boost] [chrono] v0.4.5 Documentation update + warnings
> removal + bug fixes
>>
>>Waiting for the review I plan to add yet a lightweight stopwatch, as
> suggested by Tom Tan on a personal mail, 
>>which stores a reference to a generalization of the Clock duration or
> an accumulator of the Clock duration.
>> I'll concentrate also in improving the documentation and the tests. 
> Hi Vincente, 
> Thanks for the feature. One more request, can you make this following
> specialization work?

Could you elaborate a little bit?

>    //typedef stopclock_accumulator< boost::chrono::process_cpu_clock >
> process_cpu_stopclock_accumulator;
> It's commented out in your source code, I assume it does not compile
> yet. 

Yes. It doesn't compile because boost::chrono::process_cpu_clock is not really a Clock. 
This line is also commented:
    //typedef stopclock< boost::chrono::process_cpu_clock > process_cpu_stopclock;

> In general, I'd like to see process_cpu_clock to be supported as
> the first-class citizen like process_real_cpu_clock,
> process_user_cpu_clock and so on.

Me too. Long time ago a tryed it, but I didn't reach to model it completly in terms of the Clock requirements. I will try again if find an idea on how to do it.

Best,
Vicente