c++ - WIll Boost的版本带有现代C++ "cutoff"吗？

Question

现在使用C++ 17 published，标准库现在涵盖了甚至更多的Boost库:可选，变体，任何，ASIO(在Networking TS中)，协程(在TS中)等等。除了标准中已经包含的gob和Boost的gob，还请参见this answer。我意识到某些标准化版本的设计空间选择与Boost的略有不同，但本质上是相同的。
鉴于这一事实，是否有计划发布Boost的替代版本(或只是-一个新的主线版本)，其中包括:

将大多数或所有这些功能作为Boost库

让其余的Boost代码依靠它们在标准库

中的可用性

让Boost代码至少依赖于C++ 17语言，以使生活更轻松，并且代码对开发人员更易理解

？
如果不是-这是因为Boost设计选择的重要性吗？麻烦太多了吗？担心“项目 fork ”？
注意:这是一个有用的问题，因此请不要提供您的意见或这是否是一个好主意。

Answer 1

与许多当前现有的标准C++库实现相比，Boost具有更好的实现。

注意:

在最新版本的编译器中可能会解决某些问题，在撰写本文之前，我没有重新检查所有内容。

Boost非常保守，并且支持许多旧的编译器。即使最新的编译器已修复所有问题，较旧的版本仍必须工作。

关于Unicode，我假设C++程序将尝试遵循UTF-8 Everywhere。

Boost.Filesystem vs <filesystem>
Windows在两个C/C++运行时中均不支持Unicode，例如您不能将标准库切换为支持Unicode的窄字符集(UTF-8)。结果，与 std::filesystem::path序列一起使用时， char始终采用非unicode编码。有 std::filesystem::u8path，但是写imot的 std::filesystem::path p = some_char_sequence太简单了。任何使用 std::filesystem并支持Windows的代码库都必须不断地与之抗争。

Boost.Filesystem允许用户指定要用于 path对象的语言环境。 Boost.Locale可用于在Windows上创建UTF-8语言环境，从而消除了此问题。 Std.filesystem不允许您执行此操作。

Boost.System与 <system_error>
在具有glibc的Linux上:

std::error_category::message虽然应该安全，但不是线程安全的。 Boost.System至少尝试为每个平台提供线程安全的实现。

系统类别无法测试与标准错误条件的等效性。

在Windows(MSVC)上，它在多个地方损坏:

std::system_category返回的错误消息的结尾带有令人讨厌的“\r\n”，在其他任何地方都不会发生。 Boost.System明确地修剪了那些。

如果使用跨dll，则std::error_category的比较地址不适用于一般类别和系统类别。 Boost.System从来没有这个问题。

使用当前用户编码返回错误消息(绝不使用UTF-8)。从技术上讲，这是允许的，因为标准未在此处指定使用的编码，但对任何人都没有帮助。尽管Boost.System做了同样的事情(这里不应该提到吗？)。

标准错误类别是静态局部单例，因此通过std::atexit注册析构函数。第一次从另一个atexit处理程序访问category时。这可能是一个问题，并且可能导致死锁(因为任何隐式锁定)。我过去有过这个经验。

系统类别无法像Boost.System这样做一样将WinAPI错误代码与POSIX错误代码进行匹配(首先是该功能的全部内容)。

在MSVC12(Visual Studio 2013)上，比较错误类别不适用于所有dll。这是Boost支持的编译器之一。 Boost.System没有此类问题。

关于 <system_error>的可悲部分是 <filesystem>和将来的网络库(ASIO)都严重依赖它，因此在Windows上它们都有些破损。

Boost.Thread与 <mutex>， <condition_variable>， <shared_mutex>。

直到最近在Windows和MSVC上，由于在内部使用惰性初始化，在dll中实例化时， std::condition_variable和 std::mutex可能会导致死锁。对于MSVC14(Visual Studio 2015)，至少应针对 std::mutex修复此问题，因为它已被重写为在内部使用SRW锁，但是我不确定条件变量。 MSVC12(Visual Studio 2013)肯定有很多错误。

如果您需要读取器-写入器锁，那么了解它是否有利于读取器或写入器可能非常重要。标准 std::shared_mutex不允许您指定此行为，并且根据 the original proposal这样做是因为存在一种算法，该算法允许实现不偏爱这两种情况并尝试防止两者的饥饿(某种“公平”锁定)。原始实现方式 boost::shared_mutex遵循此算法，并且不是基于 pthread_rwlock_t(由于POSIXas std::shared_mutex的要求，它通常对读者有利。Imo这意味着 std::shared_mutex在许多系统上的实现都较差。尽管Boost实现也不是最快的。