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