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

On 8/9/2019 2:48 AM, Alexander Grund via Boost wrote:

Am 09.08.19 um 08:23 schrieb degski via Boost:

...

On Fri, 9 Aug 2019 at 04:01, Howard Hinnant via Boost wrote:

...

The pitch:  boost::chrono, and other boost::libs needs to defer to std::chrono for C++11 and later.

This library by Edward achieves the above not only for boost::chrono, but Boost-wide: https://github.com/eldiener/cxx_dual . From the date of the last commit, one can deduce, though, that this does not cover C++17 [but that might not be so urgent/relevant].

Docs: https://eldiener.github.io/cxx_dual/doc/html/index.html .

As it was often discussed for Boost to "switch to C++11", why burden the maintainers with the old cruft?

My proposal would be: Implement Boost.Chrono in terms of std::chrono. (Just seen Atharva said the same) This requires: - Identify differences - Replace Boost.Chrono types with typedefs to same std::chrono types (or maybe just using namespace std::chrono inside boost::chrono?) - Adapt functions only contained in Boost.Chrono

As to "dropping C++98 compatibility" I repeat previous arguments: - People using latest Boost probably don't use pre-C++11 compilers - No guarantee about C++98-compatibility was ever made, each library is free to drop such support at any point - This support would trickle down to dependent libraries

On the proposed alternative via cxxd: This won't work. If Boost internals use CXXD they will end up using either std::chrono or boost::chrono which will result in API and/or ABI incompatibility.

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.

Compare this to scoped enum usage in Boost.Filesystem in the API which made the library compiled in pre-C++11 mode unusable to user code in post-C++11 code (and vice versa) and required subsequent fixes to work-around that.

Alex

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost