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

Subject: Re: [boost] [chrono] Interoperability with ICL and common concepts
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-03-15 16:25:22

2011/3/15 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> Joachim Faulhaber wrote:
>> 2011/3/15 Stewart, Robert <Robert.Stewart_at_[hidden]>:
>>
>> > Why can't ICL have a customization point for the identity value that
>> > defaults to T()?  Then chrono can customize that (assuming there
>> > is a suitable value to use).
>>
>> Hmm ... good simple question. So this implies a solution like this:
>>
>> //=== in or under boost/chrono/chrono.hpp ==================
>>
>> namespace boost{namespace icl
>> {
>>     template<class Type>struct identity_element;
>>
>>     template<class Rep, class Period>
>>     struct identity_element<boost::chrono::duration<Rep,Period> >
>>     {
>>         typedef boost::chrono::duration<Rep,Period> duration_type;
>>         typedef identity_element type;
>>
>>         static duration_type value()
>>         {
>>             return duration_type::zero();
>>         }
>>     };
>> }}
>>
>> //==========================================================
>>
>> right?
>
> That looks pretty good, except perhaps instead of declaring
> identity_element in the chrono header,

hmm, this was my c++ mini satori of the day, because I realized
authors of Boost.Chrono can avoid to do

> it should
> include <boost/icl/identity_element.hpp>

just that!

Recall, I wanted ICL to be Chrono agnostic and Chrono to be ICL agnostic. Why?

Because ICL shall interoperate out of the box with Boost.Onorhc and
Chrono with Boost.LCI libraries that will be written in the future.

> and just specialize for chrono::duration.
> That leaves ICL as the sole owner of the primary specialization.

Would there be any negative consequences otherwise?

Cheers,
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de