Joachim Faulhaber wrote:
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 :)
Hi, I think however that you need to add the indirections as soon or later you will find a user that is unable to change the class she uses and need a configuration point. Between Boost friends I understand that this open configuration is not needed but ... ;-) HTH, 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.