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-17 16:37:04

2011/3/17 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> Joachim Faulhaber wrote:
>> 2011/3/16 Stewart, Robert <Robert.Stewart_at_[hidden]>:
>> > Joachim Faulhaber wrote:
>> >>
>> >> Recall, I wanted ICL to be Chrono agnostic and Chrono to be
>> >> ICL agnostic.
>> >
>> > You make a good point, but I'd expect that the Chrono
>> > specialization would be in a special header that only ICL users
>> > would include.
>>
>> You know how people are, particularly under time pressure. If things
>> don't work instantly, a high percentage abandons the effort and tries
>> something else. Some of those who don't give up will have difficulties
>> to find the clues for ICL-interoperability and the exact name of that
>> header file in the docs. Why imposing all that hassle on users, if the
>> interoperability, that doesn't need additional includes and no
>> customization points is so straight forward:
>>
>> (1) A default constructor that is initialized with zero
>> (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.

Hi Robert :)

> I have written half a dozen replies to you arguing various points,

the conversation we had in this thread was very helpful for me to get
clear about various aspects of the problem. So for me the issues are
kind of settled and I am happy that Vicente and Hinnant agreed to my
proposals :)

> but I keep coming back to this: regardless of whether the
> customization is done as you or I have suggested, the only
> way to ensure the code is correct is for a library providing
> such customizations to include a test case that builds some
> ICL code using that library's customized type(s).

I think the question of correctness goes beyond what is required for
interoperability. std::set for instance requires an ordering and
assumes by default that data parameter T implements 'operator <' for
client code. If client class T does not provide < the author of T can
provide adapter code

struct MyLess { bool operator()... }

If T were from a Boost.Tee library. The author would probably provide
'operator <' to ensure seamless interoperability with std::set.
Whether the implementation of 'operator <' is correct is a different
story and will probably be ensured by tests for Boost.Tee.

> Following my suggested approach, the compiler can verify
> that the template parameter lists agree during phase one
> template parsing.  Following your approach, the compiler
> cannot verify even that much.  However, that's an incomplete
> test at best, so it's hardly a compelling argument.

The glue is IMO the understanding of the common concepts used by the
generic library and its client code. In the example case of Boost.Tee
it is the common understanding of a total or a strict weak ordering.
Between ICL and Chrono it's the common understanding of time_points or
what I've called equidistant scalar types, which I think is the
underlying concept of say time and temperature scales (except for
Kelvin).

Cheers,
Joachim

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