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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2019-08-09 12:11:20

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

And also

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