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.