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

From: Edward Diener (eldiener_at_[hidden])
Date: 2019-08-09 18:27:26

On 8/9/2019 9:57 AM, Alexander Grund via Boost wrote:
>  > Obviously cxxd does not have to go to great lengths to make this work 
> for the end-user,
> 
> Just picked this quote but it applies to more: The use-case for cxxd is 
> another than what is intended for a boost-wide solution. As you write 
> yourself: It is great for one-off code.
> In most projects using Boost you don't manually link a boost lib, but 
> use CMake (or similar). Having more variants means more switches and 
> complicate the process
> 
>  >So you want to all Boost libraries which currently support 
> boost::chrono to also support std::chrono in c++11 mode or higher with 
> additional interfaces for using std::chrono ? Sure, go ahead if you 
> think that is viable. That's what everybody currently does now anyway. I 
> personally do not relish that sort of work, which is why I created cxxd 
> in the first place.
> 
> No. What I and Atharva propose is essentially: `namespace boost::chrono{ 
> using namespace std::chrono; }`. All libraries which use boost::chrono 
> will now automatically work with std::chrono and users can use 
> boost::chrono or std::chrono to call into any boost library.

As long as there is no difference in functionality between boost::chrono 
and std::chrono, and as long as boost:;chrono is fine with being a C++11 
on up library, your technique as specified above should work. But in 
that case we might as well tell end-users about it and that they might 
want to transition directly to std::chrono and stop using boost::chrono.

> 
> The idea is: (Almost?) all types in std::chrono have exact equivalents 
> in boost which can simply be used and the boost types can be removed. 
> Additional functionality provided by Boost (if there is any) should be 
> changed to rely on std::chrono types (if they even need to, due to the 
> aliasing above)

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.

> 
> 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 
boost::chrono.