Re: [boost] [chrono] Interoperability with ICL and common concepts

Subject: Re: [boost] [chrono] Interoperability with ICL and common concepts
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2011-03-15 14:19:04

On Mar 15, 2011, at 2:00 PM, Vicente Botet wrote:

> 
> Joachim Faulhaber wrote:
>> To summarize, for a domain type Dom, Icl expects
>> Dom(), <, ++, --
>> and if dom is a equidistant scalar type we expect an associated type
>> Dom::difference_type
>> to be defined.
>> 
>> 
>> This choice has not been taken for chrono::durations, which is a
>> little inconsistent also, because interestingly for its
>> chrono::time_point type the semantic is just the desired one.
>> 
> 
> Yes, you are surely right. time_point could have a default constructor, and
> have a epoch function. Howard, what do you think?

The current std::chrono::duration default constructor has this definition:

constexpr duration() = default;

The rationale for this is to give the client and the Rep author as many options as possible:

typedef std::chrono::duration<long long> D;

D d1;  // d1.count() uninitialized - speed
D d2 = D();  // d2.count() zero-initialized - safety if you believe 0 is safe

typedef std::chrono::duration<BigInt> CustomD;

CustomD d3;  // d3.count() default constructed

The author of BigInt may decide that 0 is the best default value.  *Or* he might decide that nan is the best default value (personally I'd be tempted to go with nan).  We did not want to dictate that a default-constructed duration always represented zero, as this decision would have dubious qualities from a safety point of view.

For time_point a default constructed object is specifically documented to have the value "epoch", and duration's static zero() function is used to initialize it.  It was felt this was more useful for time_point.  Though time_point will most often be constructed from the value returned by now().

-Howard