From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2019-08-12 08:24:01
Am 09.08.19 um 20:27 schrieb Edward Diener via Boost:
> If there is additional functionality in boost::chrono that is not in
> std::chrono it probably can not rely on std::chrono to provide it.
> Furthermore if there is additional functionality in std::chrono that
> is not in boost::chrono your technique will expose it to users of
> boost::chrono, and they would need to be told about it in the docs.
The point is: With the proposed change users can just pass any
std::chrono type into boost::chrono and it will work (because they are
the same). If the functionality called is the same as std::chrono, then
that will be used. Otherwise the function from boost::chrono will be
used. But all the *types* (classes) will be std::chrono.
>> What I added was to NOT provide alternatives to C++11 and simply
>> require them which avoids the need to create variants for the
>> different standards.
> Sure, because with your suggested change you are assuming a standard
> of C++11 on up for boost::chrono and all Boost libraries which use
This is why I referenced the discussion of "Boost switch to C++11" in
which the essence was: Any library who wants to stop maintaining old
standards is free to do so.
> An intermediate step might be to e.g. let boost duration inherit from
std duration and add a implicit conversion constructor. That way ADL
should continue to work as expected and previously distinct types would
remain distinct types. However it would still require c++11 and there
might be more subtle ways in which this breaks existing code.
This actually sounds like a reasonable way to do this in small steps. In
the first release use boost::chrono types inheriting from std::chrono
and implicit conversions from/to them which would already solve the
interface problem: A boost library taking boost::chrono can no take
either and boost libs can even switch to using std::chrono instead. And
it would reduce maintenance costs as boost::chrono would considerably
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk