2011/3/17 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2011/3/16 Stewart, Robert <Robert.Stewart@sig.com>:
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