Am 09.08.19 um 11:33 schrieb degski via Boost:
This library is designed with the specific purpose of NOT burden maintainers with 'old cruft'.
Unless a library uses different public/protected functionality based on the choice between boost::chrono or std::chrono there will be no API incompatibility for the library itself. As far as ABI incompatibility I discuss in the cxxd docs how a shared library can produce different versions based on the cxxd choice for a dual library. For header-only
And also libraries, which is a good part of Boost, ABI incompatibility does not exist AFAICS, but maybe I am missing what you mean when you say that. And also
Boost.Asio does exactly this for its timer classes -- use boost::chrono if compiled pre-C++11 and otherwise use std::chrono.
As implemented, this is a pain from the users perspective
To summarize: Boost.Asio does basically what cxxd does: Wrap either namespace in its own. And it has to go some lengths to make this work. And the mentioned approach of generating variants depending on which ABI is generated would be an even larger pain for the users. Now among all those variants for debug/release, static/shared runtime, static/shared boost, version, ... now there will also be variants depending on the chrono used (or C++ standard used). This IS a burden compared to: `boost::chrono == std::chrono with utility functions` (not sure what boost provides over the std) The discussed use of `auto_link` does not work for the majority (Linux, CMake, ...) And for header-only libs: You still have the problem, that (apparently) Boost.Chrono offers functionality which is a superset of std::chrono which you won't be able to use. Example: `boost::chrono::do_cool_thing(cxxd::chrono::hours(42))`. If cxxd==std then `do_cool_thing` might not work as it expects a `boost::chrono::hours`