WIll Boost have a version with a modern-C++ "cutoff"?

Question

With C++17 now published, even more of Boost's libraries are now covered by the standard library: optional, variant, any, ASIO (in the Networking TS), coroutines (in a TS) and more. This, in addition to the gobs and gobs of Boost stuff already in the standard, see this answer. I realize that some of the standardized versions have slightly different design space choices than Boost's, but essentially it's the same.

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

• Foregos most or all of these features as Boost libraries
• Lets the rest of the Boost code rely on their availability in the standard library
• Lets the Boost code rely on the language being at least C++17, to make life easier and the code more scrutable to developers

?

If not - is this because of the importance of the Boost design choices? Too much hassle? Fear of "project bifurcation"?

Note: This is an informative question, so please don't provide your opinion or whether this would be a good idea or not.

Answer 1

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

Note that:

• Some issues might be fixed in the latest versions of compilers, I didn't recheck everything before writing this post.
• Boost is quite conservative and support many old compilers. Even if the latest compiler has everything fixed, older version still have to work.
• With regards to Unicode, I assume C++ programs will try to follow UTF-8 Everywhere.

Boost.Filesystem vs <filesystem>

Windows has no support for Unicode in both C/C++ runtimes e.g. you cannot switch standard library to Unicode-aware narrow character set (UTF-8). As the result std::filesystem::path always assumes non-unicode encoding when used with char sequences. There is std::filesystem::u8path for this, but writing std::filesystem::path p = some_char_sequence imo is way too easy. Any codebase that uses std::filesystem and supports Windows will have to battle this constantly.

Boost.Filesystem allowed user to specify locale to be used for path objects. Boost.Locale could be used to create UTF-8 locale on Windows, eliminating this issue. Std.filesystem does not allow you to do this.

Boost.System vs <system_error>

On Linux with glibc:

• std::error_category::message is not thread safe, although it should be. Boost.System at least tries to provide thread-safe implementation for every platform.
• System category is not able to test for equivalency with standard error conditions.

On Windows (MSVC) it is broken in multiple places:

• Error messages returned by std::system_category have annoying "\r\n" at the end, which does not happen anywhere else. Boost.System explicitly trims those.
• Comparing addresses of std::error_category does not work for generic and system categories if used cross-dll. Boost.System never had this issue.
• Error message is returned using current user enconding (never UTF-8). Technically this is allowed since standard does not specify encoding used here, but it doesn't help anyone. Although Boost.System did the same (should not be mentioned here?).
• Standard error categories are static-local singletons and thus register destructor through std::atexit. When category is accessed for the first time from another atexit handler. This might be a problem and can cause deadlocks (as any implicit locking). I had experience with this in the past.
• System category is not able to match WinAPI error codes against POSIX error codes the same way Boost.System does this (something that was the whole point of this facility in the first place).
• On MSVC12 (Visual Studio 2013) comparing error categories does not work across dlls. This is one of compilers supported by Boost. Boost.System had no such issues.

The sad part about <system_error> is that <filesystem> and future networking library (ASIO) both rely on it heavily, so both get a little 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 deadlock when instantiated in a dll due to using lazy initialization internally. With MSVC14 (Visual Studio 2015) this should be fixed at least for std::mutex since it was rewritten to use SRW locks internally, but I am not sure about condition variables. MSVC12 (Visual Studio 2013) definitely has a lot of bugs here.

If you need a reader-writer lock, it might be very important to know if it favors readers or writers. Standard std::shared_mutex does not allow you to specify this behavior and according to the original proposal this was done because there is an algorithm that allows implementation to favor neither and try to prevent starvation of both (somewhat "fair" lock). Original implementation e.g. boost::shared_mutex follows this algorithm and is not based on pthread_rwlock_t (which usually favors readers due to requirements of POSIXas std::shared_mutex. Imo this means std::shared_mutex has a poor implementation on many systems. Although Boost implementation is not the fastest one either.