Boost 会有一个带有现代 C++“截止”的版本吗？

Question

现在使用 C++17 published，标准库现在涵盖了更多 Boost 库：可选、变体、任意、ASIO（在网络 TS 中）、协程（在 TS 中）等等。除了标准中已有的 Boost 东西的 gobs 和 gobs 之外，请参阅this answer。我意识到一些标准化版本的设计空间选择与 Boost 的略有不同，但本质上是相同的。

鉴于这一事实，是否有或曾经有计划发布 Boost 的替代版本（或只是 - 一个新的主线版本）：

• 放弃大部分或所有这些功能作为 Boost 库
• 让其余的 Boost 代码依赖于它们在标准库中的可用性
• 让 Boost 代码依赖于至少为 C++17 的语言，让开发人员的工作更轻松，代码更易于审查

?

如果不是 - 这是因为 Boost 设计选择的重要性吗？太麻烦了？害怕“项目分叉”？

注意：这是一个信息性的问题，所以请不要提供您的意见或这是否是一个好主意。

Answer 1

Boost 比目前许多标准 C++ 库的现有实现具有更好的实现。

请注意：

• 一些问题可能会在最新版本的编译器中得到修复，在写这篇文章之前我没有重新检查所有内容。
• Boost 相当保守，支持许多旧的编译器。即使最新的编译器已经修复了所有问题，旧版本仍然可以工作。
• 关于 Unicode，我假设 C++ 程序会尝试遵循 UTF-8 Everywhere。

Boost.Filesystem 与 <filesystem>

Windows 在两个 C/C++ 运行时都不支持 Unicode，例如您不能将标准库切换到支持 Unicode 的窄字符集 (UTF-8)。因此，std::filesystem::path 在与char 序列一起使用时始终采用非 unicode 编码。有std::filesystem::u8path，但写std::filesystem::path p = some_char_sequence imo 太容易了。任何使用 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 处理程序访问类别时。这可能是一个问题，并可能导致死锁（与任何隐式锁定一样）。我过去有过这方面的经验。
• 系统类别无法将 WinAPI 错误代码与 POSIX 错误代码进行匹配，就像 Boost.System 执行此操作一样（这首先是该工具的重点）。
• 在 MSVC12 (Visual Studio 2013) 上，比较错误类别无法跨 dll 进行。这是 Boost 支持的编译器之一。 Boost.System 没有此类问题。

关于<system_error> 的可悲之处在于，<filesystem> 和未来的网络库 (ASIO) 都严重依赖它，因此在 Windows 上都会出现一些问题。

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

直到最近在 Windows 和 MSVC 上 std::condition_variable 和 std::mutex 在 dll 中实例化时可能会由于内部使用延迟初始化而导致死锁。使用 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 实现不是最快的要么。