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

Subject: Re: [boost] [thread] Integration with Chrono and DateTime (was: [release][1.52] Release Notes)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-12 18:01:54

Le 12/10/12 23:28, Andrey Semashev a écrit :
> 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).
Note that Boost.Chrono could be configured as a header only library.

BTW, Boost.Thread depends also on Boost.System. Do you avoid already 
this dependency?
>> 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?
This could be possible but this is not a priority for me, if you want to 
provide a patch I will integrate it if the design is simplified, but I 
don't see how you could provide the time related function with the 
Boost.Chrono interface in this case.
>>> 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.
If you need time related facilities, then you will need to move to 
Boost.Chrono before boost 1.56.
>
>>> 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.
>
You are surely right, but this is not a priority for me. What others think?

Best,
Vicente