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

From: Edward Diener (eldiener_at_[hidden])
Date: 2019-08-09 13:45:00

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.