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

Subject: Re: [boost] [chrono] Interoperability with ICL and common concepts
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-03-17 09:43:07

Joachim Faulhaber wrote:
> 
> 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.
> 
> 

Joachim, 

please could you create a ticket for that extension feature :)

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/chrono-Interoperability-with-ICL-and-common-concepts-tp3357088p3384548.html
Sent from the Boost - Dev mailing list archive at Nabble.com.