On 8/9/2019 8:11 AM, Alexander Grund via Boost wrote:
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.
Obviously cxxd does not have to go to great lengths to make this work for the end-user, as it is already done for a number of dual libraries, and the end-user just has includes the correct cxxd header file for the correct dual library. For chrono the header file is 'boost/cxx_dual/chrono.hpp'.
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).
I agree with you that designing variant shared libraries is complicated. But it is what all shared libraries do if they want to give the end-user choices of what they want, as you specify above. But I do get your point.
This IS a burden compared to: `boost::chrono == std::chrono with utility functions` (not sure what boost provides over the std)
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.
The discussed use of `auto_link` does not work for the majority (Linux, CMake, ...)
You can depend or not depend on auto-link whether you use cxxd or not. Without cxxd you still have to instruct the end-user how to link a shared library if autolink is not available. It would be no different with using cxxd, except that you will have more shared library variant names to tell the end-user about to do his manual linking.
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`
Using cxxd you can still write one-off compile time code which depends on which dual library is being used, either boost::chrono or std::chrono in this particular case. A preprocessor macro ( CXXD_HAS_STD_CHRONO in our case ) is available for each dual library which tells the end-user at compile time which choice is being made, so writing one-off code based on that macro is easy enough. The idea of cxxd is that writing occasional one-off code, while using the exact same syntax for the majority of your code, is much easier to do than writing completely separate code, which does the exact same thing in the vast majority of cases, for each public/protected interface which uses a particular dual library choice.