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 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.
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
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk