Boost logo

Boost :

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
   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
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

    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

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at