Joachim Faulhaber wrote:
Hi Vicente and Boost Chronoists,
thank you for implementing Boost.Chrono! It's a very fine piece of software :)
Thanks :)
Currently I'm checking out the usage of chrono types with icl::intervals and interval containers. Obviously, using intervals of chrono::time_points or chrono::durations can be an important use case. Also ICL already works well with other date and time data types from boost data_time, so chrono's interoperability should be at least as easy.
A problem here is, that Icl, while working instantly with built in data types (e.g. int, short, double or even int*), for other numeric types (e.g. boost::rational) or types "based on integral types" (e.g. data_time::ptime) I needed to provide adapter code.
I think it'd be ideal, if boost libraries interoperated with each other just out of the box, of course. To achive this, we have to find a common understanding of those concepts, that make a seamless interoperability work. I think, this is important work to be done, because it widens the view from one's own library perspective to a broader horizon of generic interplay.
Recall that adding an indirection use to solve a lot of problems.
The problem: There is a minimal set of requirements that Icl expects for the domain types of intervals and interval containers (1) A zero element, more precisely an identity element w.r.t. the type's composition operation, which usually is +. An assumption that works well for all built in types and many STL-types is, that we get this element by the default constructor T().
What about creating a customization point identity or zero template struct zero { T value() { return T(); } }; The user or Boost.Chrono could specialize it. template <...> struct zero<duration<...> > { T value() { return duration<...>::zero(); } };
(2) A strict weak ordering < (3) For all discrete types and for continuous numeric types: Operators ++, -- (Only pre-variants needed e.g. ++x) (3.1) For discrete types ++/-- increments/decrements by a *least step* (3.2) For continuous numeric types ++/-- increments/decrements by a *unit step*.
The same can be done for customizations points increase_unit, and decrease_unit.
(4) For such equidistant scalar types D the ICL assumes, that the type of the difference values of D is D::difference_type.
You can add another customization point template struct difference_type{ typedef typename T::difference_type; }; and specialize for the types not conforming to this trait.
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 possibility of default ctor customization is no remedy, because ICL should ideally be completely "chrono agnostic" and still interoperable. For the same reason duration::zero() is not an option.
You can always use a duration that has a representation that default construct to 0 and define the associated typedefs.
T3: chrono::time_point does not implement ++ and --. I assume this is because of the specific maths that is designed for chrono::time_points (P) and durations (D) where - : P x P -> D + : P x D -> P + : D x P -> P but + : P x P -> P //verboten
But this should not be an argument against ++ and -- because the "least steppable unit" for integral rep types as well as the "unit" for floating point rep types, that is processed by ++ and -- is the same for time_points and durations.
The problem with operators ++ and -- is that they should be equivalent to x+=1 and x-=1. As you can see there is no way if we are adding minutes, seconds, ... We could choose as default unit the one given by the duration parameter. If we added operators ++ and --, we should add time_point + Rep, Rep + time_point time_point - Rep, which are a little bit against the safety goals of Chrono. Hoping the proposals are close to the interoperability point. If the separated traits don't satisfy your design, maybe you could define a specific traits that groups all your needed traits. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/chrono-Interoperability-with-ICL-and-comm... Sent from the Boost - Dev mailing list archive at Nabble.com.