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-16 12:36:39

2011/3/16 Howard Hinnant <howard.hinnant_at_[hidden]>:
> On Mar 16, 2011, at 11:48 AM, Vicente Botet wrote:
>
>>
>> Joachim Faulhaber wrote:
>>>
>>> (2) An increment/decrement on the least steppable unit
>>> (3) A difference_type declaration
>>>
>>> Very simple, very little effort, great benefit for instant
>>> interoperability, not only with ICL but with all generic libraries
>>> that depend on this minimal set of fundamental information.
>>>
>>>
>>
>> Joachim,
>>
>> could you create a ticket for (3). I don't think this is too disruptive.
>>
>> For (2), I will rephrase your least steppable unit as follows. The semantics
>> associated to++,-- is to interpret the unit as the duration of the
>> time_point.
>>
>> Given
>> Atime_point tp;
>>
>>  tp++
>>
>> will be equivalent to
>>
>>  tp += Atime_point::duration(1);
>>
>> Howard, do you think that there is a chance this semantics could be accepted
>> for TR2?
>
> I think there's a chance.  I'm not sure enough to be able to say
> whether that chance is high or low.  The chances would probably
> improve if boost's use of it did show benefit and did not show any
> problems.

I have a large test suite for generic intervals and interval
containers. Each of the tests can be iterated over mpl::lists of
types. Currently those tests work for a great variety of types:

All numeric built in types, T*, string, boost::rational
date_time dates, times and durations

I could instantiate the test suite for a selection of variants of
chrono time_points and durations and run them on all trunk test
platforms. Also I could write something about adapter code free
concept based generic interoperability featuring Boost.Chrono and
Boost.ICL ;-) [We don't have a boost authors blog?]

> I don't immediately see any problems with this addition.

:)

I only need the pre in/decrement variant in ICL  ++i, --i.  But one
would probably add both variants in one go.

> I think it should be specified/implemented as:
>
> Returns: time_point(d_++);
>
> where d_ is the "// exposition only" member in the specification of time_point.  This will ensure that if Rep has any unusual properties associated with operator++(int), it will be picked up via duration::operator++(int) and subsequently time_point::operator++(int).
>

I don't understand this. But the aspect that is important for me from
the ICL point of view is efficiency here. For discrete domain types
operators ++ and -- are called frequently in ICL functions. So they
should be fast. IIUC the operation finally is an in/decrement on the
rep_ member which *is* fast particularly if Rep is a built in numeric
type.

Cheers,
Joachim

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