2011/3/15 Joachim Faulhaber <afojgo@googlemail.com>:
2011/3/15 Howard Hinnant <howard.hinnant@gmail.com>:
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
Hi Howard,
thanks for your comments. I understand the value and foresight of this flexible design. Yet from my point of view I would have chosen zero() as default and uninitialized as configurable option.
But anyway, maybe its the more flexible and long lasting design to separate identity_element<T> and default ctor T(). Sine c++ is about speed, uninitialized could be the standard default for T() then. I'm kind a standard agnostic :( Maybe there is already something like a std::identity_element<T> ?
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).
Hmm, personally I'm a NaN hater. Although I basically think it's healthier to start loving the world one lives in (difficult at times, if one thinks of Japan). Maybe you can bring the enlightenment and beauty of NaN to me.
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.
Not always, ok. But why not as a default?
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().
From an algebraic point of view, chrono::time_points (and durations) seem to be "pretty" isomorphic with the representing type Rep, which is a number. Roughly I'd expect that the following diagram will commute:
Let P : time_point R : Rep (representing type) f : P -> R forget Period information r : R -> P recall Period information g : functions on P and R
P ---- g ----> P | | f = f | | V V R ---- g ----> R
If functions g (additions, multiplications, .... and also compositions of them) are performed on time_points, and we take the Rep value this is the same, as if we take the Rep value and perform the same functions g on them.
So all functions on P should be the isomorphic to the same function on R. If R() yields the identity_element on Rep, then also P() should yield an identity on time_point.
Those are my thought about Chrono, correct me if I'm wrong.
Ooops, corrections above. -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de