On Oct 13, 2012 12:10 AM, "Vicente J. Botet Escriba" < vicente.botet@wanadoo.fr> wrote:
Le 12/10/12 21:51, Andrey Semashev a écrit :
On Oct 12, 2012 8:35 PM, "Vicente J. Botet Escriba" < vicente.botet@wanadoo.fr> 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.