Joachim Faulhaber wrote:
2011/3/16 Howard Hinnant <howard.hinnant@gmail.com>:
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-comm... Sent from the Boost - Dev mailing list archive at Nabble.com.