Re: [boost] Comments about N2320

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-10-29 10:02:49

Yuval Ronen wrote:
> Jeff Garland wrote:
>> Yuval Ronen wrote:
>>> Hi,
>>> After reading most of N2320, I have a few comments:
>>   ...snip several thoughts...
>>

> After reading that there is no universal time_duration type, I asked 
> myself "then what is the return type of time_point subtraction?" So I 
> looked in N2411, and saw that the answer is "nanoseconds". It also makes 
> sense given the fact the utc_time is defined to have nanoseconds 
> resolution. So my conclusion from it, is that nanoseconds /is/ that 
> universal duration_time type. All the rest are (or can be) simple 
> logic-less wrappers around nanoseconds. Had there wasn't any universal 
> time point type (utc_time), but seconds_utc_time, nanoseconds_utc_time, 
> etc, then you could say that there isn't a universal time, but as it is 
> now, I think there is.

No, there is still no universal time duration.  You can send any type that 
meets the qualifications into a sleep or wait.  As for utc_time (now renamed 
to system_time in the latest drafts) using nanoseconds, that is just an 
indication that the system_time class has a maximum resolution of nanoseconds.

> Now I also understand better the sentence that appear in N2320 in all 
> timed functions: "ElapsedTime shall be explicitly convertible to 
> nanoseconds". It's because nanoseconds are the basic for all. Now lets 

I'll check, but that's incorrect and has been removed.  They don't need to be 
convertible to nanoseconds, they need to provide get_count and a 
ticks_per_second trait to allow conversion to the system time resolution.

> say you want to allow a demanding user to write his own picoseconds 
> class. This class needs to be "explicitly convertible to nanoseconds". 
> What does it mean? The only answer I can think of is "it has an explicit 
> conversion operator to nanoseconds" (assuming C++0x have an explicit 
> conversion operator feature). That makes the picoseconds class different 
> from all the other time_duration types, because microseconds isn't 
> explicitly convertible to milliseconds, for example. And there's 
> probably a good reason it isn't convertible - because it looses 
> resolution. So why should picoseconds be convertible to nanoseconds?

It won't be -- as I said, that part of N2320 wasn't quite right.  Of course, 
the conversion problem still exists if you use a higher resolution duration 
than the system supports.  In that case, the system will round up to the 
nearest supported resolution on the system (eg: nanoseconds --> microseconds).

> So it seems to me that threading timed function should accept the 
> nanoseconds class. Any alleged picoseconds class will somehow have to 
> support rounding-conversion to nanoseconds. Don't bother threading 
> functions with that, let the picoseconds class handle it.

Yes, it will, but the time duration type provides all the machinery to support 
the needed rounding.  Frankly rounding will be the majority of the cases if 
you use nanoseconds because few systems currently have clock support at that 
resolution.

Jeff