[boost] [thread] Integration with Chrono and DateTime (was: [release][1.52] Release Notes)

Subject: [boost] [thread] Integration with Chrono and DateTime (was: [release][1.52] Release Notes)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-10-12 17:28:08

On Oct 13, 2012 12:10 AM, "Vicente J. Botet Escriba" <
vicente.botet_at_[hidden]> wrote:
>
> Le 12/10/12 21:51, Andrey Semashev a écrit :
>
>> On Oct 12, 2012 8:35 PM, "Vicente J. Botet Escriba" <
>> vicente.botet_at_[hidden]> wrote:
>>>
>>> Hi,
>>> Why you don't want to depend on Boost.Chrono?
>>
>> Because I want to minimize dependencies (especially, binary build
>> dependencies).
>
> Me too, I want to limit dependencies :)

Fair enough. Perhaps, we could absract away Boost.Thread from both
libraries? Seems like a logical solution for a case like this.

For example, Boost.Thread could define an internal interface for
integrating with time units from different libraries. Chrono and DateTime
would support this interface, and Boost.Thread could also provide the
necessary glue for std::chrono integration. I think, Boost.Thread could use
its own time units internally and use ADL-found functions to convert from
other time units. Boost.Thread will not depend on either timing library
then. Does this look viable?

>> Unlike Boost.DateTime, Boost.Chrono is not needed by my library, so this
>> would really be a false dependency.
>
> If you don't need time related thread facilities you could set
BOOST_THREAD_DONT_USE_CHRONO. Would this work for you?

Yes, that's what I'm doing now. I'm using DateTime units for timed
functions.

>> I understand that the dual interface adds more redundancy but does it
>> really require active maintenance? The code has been there for quite some
>> time, it's well tested and doesn't require additional work.
>>
>>
> Any addition code has its influence on how the library could evolve. I
really would prefer to remove these interfaces for Boost 1.56. I think that
1 year and a half is enough time to move to the new interface.

Then I think library decoupling is the right way even more.