Re: Potential project: Resolving boost::chrono conflicts with std::chrono

From: Mike (mike.dev_at_[hidden])
Date: 2019-08-19 11:51:42

> 
> So where are we at with this? Have we reached to any conclusion yet?
> 

As was previously mentioned in this thread, you should not expect 
the ML to come to any decision as it is ultimately the responsibility 
of the library maintainer to decide which way to go. I'm not sure
of the ML has come to any decision on anything over the last couple 
years anyway (except for accepting/rejecting new libraries).

>
> It’s hard to say.  The C++/English ratio is awfully low. :-) 
>

FWIW: I toyed a bit with different possible approaches: 

#####
# (I)

I made a version where I replaced the definition of boost::ratio and 
boost::chrono types and functions with their std equivalents (e.g. 
using std::chrono::duration) where possible.
This worked like a charm, with two exceptions:

1) If  BOOST_RATIO_EXTENSIONS is defined, boost::ratio provides 
    integration hooks into the mpl, which obviously are not provided 
    by the std types. I didn't check if there was any way to do the 
    same for std::ratio.
2) As mentioned before, boost::chrono provides io operators for
    duration and time point types. unless there is a 
   using namespace boost::chrono, those are expected to be found
   via ADL and of course that doesn't work anymore. 
   My quick fix, that allowed me to run all of the chrono and thread
  unit tests virtually unaltered was to:
 
   a) put the operators into their own inline namespace below
       boost::chrono
   b) And put a using namespace "boost::chrono::io_ops"
       into the global scope of the header

    Of course the latter would be completely unacceptable
    for a real implementation. In reality, the code that actually
    uses the streaming operators would have to do this.

#####
# (II)

I also looked a bit into the approach of inheriting the boost 
chrono types from std::chrono types and letting the boost::chrono 
functions wrap the native ones. It seems that in practice this 
would require far too much code chrun and potentially problematic
effects on overload resolution to be justified by the gains.

I see two realistic ways forward to solve the interoperability 
problem:
a) 1) Replacie std::boost with std::chrono. This will be a breaking
    change even for projects that are using c++11+. 
    2) Mid to long term, dependencies on boost::chrono could probably
    be removed from most boost libraries that don't need the extended
    functionalities.

    In practice this would require a period, where both versions coexist.
    (Add a off-by-default config option that makes the boost types 
     aliases for the std types, next release turn the option on by 
     default and give a deprecation warning for the old one and
     finally remove the old version).

    On the up side it is will minimize any interoperability problems and 
    will reduce the amount of code to test, maintain and compile
    (in my tests on a windows machine, compiling and running the 
    boost chrono unit tests actually took less time with the changes).
     It is also best option for projects that just start to use related Boost 
     libraries.

b) 1) Provide some free functions like "to_boost_duation/ to_std_duration"
     in Boost.Chrono that the users can use when required and 2) add
     std::chrono::overloads to other boost libraries like Boost.Thread.
 
     This is (probably) a non-breaking change but 2) requires a lot more work
     across other parts of boost and I doubt it will actually happen at all. Also,
     we are probably forever stuck with a competing set of vocabulary types 
     for chrono.

I'd be willing to help with both approaches (although apparently anonymous 
contributions are problematic due to copyright). 

Personally, I'd prefer if boost would focus on being an easy to use extension to
the standard library not yet another a competing implementation like EASTL.
As I said before: The whole purpose of a standard is to allow products of 
different vendors to easily interoperate. Establishing a competing de-facto standard 
instead of building on top of the existing standard makes things harder - not 
easier for the ECO system.

Best 

Mike