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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk