WIll Boost有一个带有现代C++"截止"的版本吗？

Question

现在已经发布了 C++ 17 ,标准库现在涵盖了更多的Boost库:可选,变体,任何,ASIO(在网络TS中),协同程序(在TS中)等等.除了标准中已有的Boost东西之外,还有这个答案.我意识到一些标准化版本的设计空间选择与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始终假定非 unicode 编码char。有std::filesystem::u8path这个，但std::filesystem::path p = some_char_sequence在我看来写起来太容易了。任何使用std::filesystem和支持 Windows 的代码库都必须不断地应对这一问题。

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

Boost.系统对比<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处理程序访问类别时。这可能是一个问题，并可能导致死锁（与任何隐式锁定一样）。我过去有过这方面的经验。
• 系统类别无法像 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不允许您指定此行为，并且根据最初的提案，这样做是因为有一种算法允许实现不偏向任何一个，并尝试防止两者的饥饿（有点“公平”锁）。原始实现例如boost::shared_mutex遵循该算法而不是基于pthread_rwlock_t（由于 POSIXas 的要求，这通常有利于读者std::shared_mutex。我认为这意味着std::shared_mutex在许多系统上的实现很差。尽管 Boost 实现也不是最快的。