Re: [boost] Comments about N2320

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-10-29 11:34:08

Jeff Garland wrote:
> Yuval Ronen wrote:
>> 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).

Okay, that makes a lot of difference. N2320 needs some fixing. However...

>> 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.

... in general (ignoring threading stuff for now), I see no point in 
providing genericity in time-duration types without parallel genericity 
in time-point types. These are too interconnected. The fact that the 
time-point type is defined to have a fixed (nanoseconds) resolution 
sterilize almost all advantages from time-duration resolution 
genericity. If sub-nanosecond resolution for time-duration is necessary, 
then I guess it's also needed for time-points.

And another small question: why make those traits a function, and not 
compile-time constants?