Le 12/10/12 23:28, Andrey Semashev a écrit :
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). Note that Boost.Chrono could be configured as a header only library.
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
BTW, Boost.Thread depends also on Boost.System. Do you avoid already this dependency? 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