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

Subject: Re: [boost] [chrono] Interoperability with ICL and common concepts
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-03-17 09:17:40

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.

I have written half a dozen replies to you arguing various points, 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).

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.

Given that my approach requires including yet another header, even when the customization is not used (and assuming such a header is included by a library's include-all header), and the need for test code to fully validate the customization, your approach is better.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.