Le 17/03/2017 à 10:18, Oswin Krause a écrit :
Could you explain what is the problem having to use also Boost.Chrono? Let me answer your question with another question: What good is it to force boost.chrono on the user? If my application does not profit from using boost::chrono over std::chrono why should i have to use it?
Well, don't use it then. Who is forcing you to use Boost.Chrono?
Here is how i see it: std::chrono + fully described by the standard and supported by all major c++ environments + described in all online standard references for c++ + we can soon expect all newcomers to know about std::chrono + can be used without adding another dependency on an external library
boost::chrono + larger functionality + very similar, but not the same as std::chrono A report on any difference is welcome. I'm not saying that there are not.
mixing both: + converting between time points? I've not think about this, but a patch is welcome. + differences in time measured /different clocks? Chrono library doesn't specify how to convert between clocks. Neither std nor boost. Could you clarify your concern? + why should there be two very similar libraries mixed in the same code?
I suspect that because you have some parts of your code that use Boost.Chrono because std::chrono is not available.However you have other parts that can use std::chrono. In this case, I would suspect that for the parts that interact you will use Boost.Chrono. Best, Vicente