Does WIll Boost have a C ++ cut-off version in a modern style?

Question

With C ++ 17 now published , even more Boost libraries are now covered by the standard library: optional, any, ASIO (in Networking TS), coroutines (in TS), and much more. This, in addition to the gobs and gobs of Boost material, is already standard, see this answer . I understand that some standardized versions have a slightly different choice of space for design than Boost, but in essence it is the same.

Given this fact, are there any plans to release an alternative version (or just a new version) of Boost, which:

• Foregos most or all of these features like Boost libraries
• The rest of the Boost code depends on their availability in the standard library.
• Allows Boost code to rely on a language that is at least C ++ 17 to make life easier, and the code more understandable for developers.

?

If not, is it because of the importance of choosing a Boost design? Too much trouble? Fear of "project bifurcation"?

Note. This is an informative question, so please do not indicate your opinion on whether this will be a good idea or not.

Answer 1

Boost has a better implementation than many existing implementations of the C ++ standard library.

Note that:

• Some problems can be fixed in the latest versions of compilers, I did not double-check everything before writing this post.
• Boost is pretty conservative and supports many older compilers. Even if the last compiler fixed everything, the older version should still work.
• As for Unicode, I assume that C ++ programs will try to follow UTF-8 Everywhere .

Boost.Filesystem vs <filesystem>

Windows does not support Unicode in both C / C ++ modes, for example. you cannot switch the standard library to the Unicode narrow-gauge character set (UTF-8). As a result, std::filesystem::path always uses non-Unicode encoding when used with char sequences. There is std::filesystem::u8path , but writing std::filesystem::path p = some_char_sequence imo is too simple. Any code base that uses std::filesystem and supports Windows will have to constantly deal with it.

Boost.Filesystem allows the user to specify the language that will be used for path objects. Boost.Locale can be used to create the UTF-8 locale on Windows, fixing this problem. Std.filesystem does not allow you to do this.

Boost.System vs <system_error>

On Linux with glibc:

• std::error_category::message not thread safe, although it should be. Boost.System at least tries to provide a thread-safe implementation for each platform.
• The system category cannot verify equivalence with standard error conditions.

On Windows (MSVC), it is divided into several places:

• The error messages returned by std::system_category ultimately annoy "\ r \ n", which no longer happens. Boost.System explicitly trims them.
• Comparing addresses std::error_category does not work for general and system categories when using cross-dll. Boost.System has never had this problem.
• The error message is returned using the current user (never UTF-8). This is technically permitted, since the standard does not indicate the encoding used here, but it does not help anyone. Although Boost.System did the same (not worth mentioning here?).
• The standard error categories are static local singleton and thus register the destructor through std::atexit . When a category is opened for the first time from another atexit handler. This can be a problem and can lead to locks (like any implicit lock). I have had experience with this in the past.
• The system category cannot match WinAPI error codes with POSIX error codes in the same way that Boost.System does this (something that was the whole thing for this object in the first place).
• In MSVC12 (Visual Studio 2013), error category comparison does not work in a DLL. This is one of the compilers supported by Boost. Boost.System had no such problems.

The sad part about <system_error> is that the <filesystem> and the future network library (ASIO) rely heavily on it, so both are a bit broken on Windows.

Boost.Thread vs <mutex> , <condition_variable> , <shared_mutex> .

Until recently, on Windows and MSVC std::condition_variable and std::mutex could cause a deadlock when creating an instance in dll due to the use of lazy initialization inside. With MSVC14 (Visual Studio 2015), this should be fixed, at least for std::mutex , as it was rewritten for internal use of SRW locks, but I'm not sure about the variable conditions. MSVC12 (Visual Studio 2013) definitely contains a lot of bugs.

If you need a read-write lock, it can be very important to know if it supports readers or writers. The standard std::shared_mutex does not allow you to specify this behavior and, in accordance with the original proposal, this was done because there is an algorithm that allows you to implement do not encourage or try to prevent the hunger of both (somewhat "honest" lock). The original implementation, for example. boost::shared_mutex follows this algorithm and is not based on pthread_rwlock_t (which usually favors readers due to the requirements of POSIXas std::shared_mutex .Imo this means that std::shared_mutex has a poor implementation on many systems. Although the Boost implementation is not the fastest either .