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

On Fri, 9 Aug 2019 at 10:11, Alexander Grund via Boost < boost@lists.boost.org> wrote:

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

Did you read https://eldiener.github.io/cxx_dual/doc/html/index.html#cxxd.introduction ? This library is designed with the specific purpose of NOT burden maintainers with 'old cruft'. Having said that, the 'old cruft' is in those Boost libraries, not in the std. degski -- @realdegski https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-pena... "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

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.

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.

On 8/9/2019 2:23 AM, degski via Boost wrote:

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].

If there is something added in C++17 that affects using cxx_dual I would love to hear about it, but I doubt that is presently the case.

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

On Aug 10, 2019, at 1:48 AM, Robert Ramey via Boost wrote:

It's inexplicable to me why vendors make their own (often inferior) versions of the boost library versions. Have they nothing better to do with their money? If they want, the could send some my way.

In the case of <chrono>, std::chrono came first, at least in implementation in libc++. In other cases, corporate policy may not accept the boost copyright. And in other cases, a std::lib maintainer may feel the need to become expert in the subject matter since he/she will be at the tip of the spear in supporting it. Though multiple implementations has its down side, it also has its upsides, such as better chances at minor improvements, both in API and performance. Independent implementations are also an excellent technique for improving the specification. Howard

On 8/10/19 1:51 PM, Robert Ramey via Boost wrote:

In case it wasn't obvious, this is one more bullet in my campaign to see the standards committee narrow it's scope to the things that only such a committee can do. That is:

a) core language syntax and semantics b) core libraries which place a common interface on underlying machine or operating system implementations

Other stuff should be considered separately.  Preferably by some other organization but at least by a separate committee. The current structure is failing to scale and the problem is growing (exponentially?). I'm sorry I continue to harp on this, but I'm not getting traction.  Note that a huge portion of standard libraries have their origin in other organizations - stl, boost, and others.  The committee has a poor track record in delivering quality libraries in a timely manner.

At risk of derailing this, at the institutions which I have previously worked don't use boost, and don't really go outside the core of the language.  Such a restriction would only result in a even more significant drop in usage and interest unless the core language can be considered *complete*.  While your argument has merit from a puristic perspective, I contest in an applied view it would be a death knell for the language and they retreat to C and assembly.  There are too many who are still unwilling to learn or adapt more, and the only way to get things to move forward for anybody is if the core language takes the load to add functionality for those who are willing to learn it.

So where are we at with this? Have we reached to any conclusion yet?

As was previously mentioned in this thread, you should not expect the ML to come to any decision as it is ultimately the responsibility of the library maintainer to decide which way to go. I'm not sure of the ML has come to any decision on anything over the last couple years anyway (except for accepting/rejecting new libraries).

It’s hard to say. The C++/English ratio is awfully low. :-)

FWIW: I toyed a bit with different possible approaches: ##### # (I) I made a version where I replaced the definition of boost::ratio and boost::chrono types and functions with their std equivalents (e.g. using std::chrono::duration) where possible. This worked like a charm, with two exceptions: 1) If BOOST_RATIO_EXTENSIONS is defined, boost::ratio provides integration hooks into the mpl, which obviously are not provided by the std types. I didn't check if there was any way to do the same for std::ratio. 2) As mentioned before, boost::chrono provides io operators for duration and time point types. unless there is a using namespace boost::chrono, those are expected to be found via ADL and of course that doesn't work anymore. My quick fix, that allowed me to run all of the chrono and thread unit tests virtually unaltered was to: a) put the operators into their own inline namespace below boost::chrono b) And put a using namespace "boost::chrono::io_ops" into the global scope of the header Of course the latter would be completely unacceptable for a real implementation. In reality, the code that actually uses the streaming operators would have to do this. ##### # (II) I also looked a bit into the approach of inheriting the boost chrono types from std::chrono types and letting the boost::chrono functions wrap the native ones. It seems that in practice this would require far too much code chrun and potentially problematic effects on overload resolution to be justified by the gains. I see two realistic ways forward to solve the interoperability problem: a) 1) Replacie std::boost with std::chrono. This will be a breaking change even for projects that are using c++11+. 2) Mid to long term, dependencies on boost::chrono could probably be removed from most boost libraries that don't need the extended functionalities. In practice this would require a period, where both versions coexist. (Add a off-by-default config option that makes the boost types aliases for the std types, next release turn the option on by default and give a deprecation warning for the old one and finally remove the old version). On the up side it is will minimize any interoperability problems and will reduce the amount of code to test, maintain and compile (in my tests on a windows machine, compiling and running the boost chrono unit tests actually took less time with the changes). It is also best option for projects that just start to use related Boost libraries. b) 1) Provide some free functions like "to_boost_duation/ to_std_duration" in Boost.Chrono that the users can use when required and 2) add std::chrono::overloads to other boost libraries like Boost.Thread. This is (probably) a non-breaking change but 2) requires a lot more work across other parts of boost and I doubt it will actually happen at all. Also, we are probably forever stuck with a competing set of vocabulary types for chrono. I'd be willing to help with both approaches (although apparently anonymous contributions are problematic due to copyright). Personally, I'd prefer if boost would focus on being an easy to use extension to the standard library not yet another a competing implementation like EASTL. As I said before: The whole purpose of a standard is to allow products of different vendors to easily interoperate. Establishing a competing de-facto standard instead of building on top of the existing standard makes things harder - not easier for the ECO system. Best Mike

Am 19.08.19 um 18:10 schrieb Peter Dimov via Boost:

Mike wrote:

...

2) As mentioned before, boost::chrono provides io operators for duration and time point types. unless there is a using namespace boost::chrono, those are expected to be found via ADL and of course that doesn't work anymore.

Interesting point. IMO this is just a minor breaking change which can simply be documented. The effect is a (more or less) clear compiler error and the solution a single line to add which also works with the existing implementation (although it is not required there).