c++ - 为什么 std::unique_lock 使用类型标签来区分构造函数？

Question

在 C++11 中，std::unique_lock constructor被重载以接受类型标签 defer_lock_t、try_to_lock_t 和 adopt_lock_t:

unique_lock( mutex_type& m, std::defer_lock_t t );
unique_lock( mutex_type& m, std::try_to_lock_t t );
unique_lock( mutex_type& m, std::adopt_lock_t t );

这些是空类(类型标签)defined as follows :

struct defer_lock_t { };
struct try_to_lock_t { };
struct adopt_lock_t { };

这允许用户通过传递 pre-defined instances 之一来消除三个构造函数之间的歧义。这些类:

constexpr std::defer_lock_t defer_lock {};
constexpr std::try_to_lock_t try_to_lock {};
constexpr std::adopt_lock_t adopt_lock {};

我很惊讶这不是作为 enum 实现的。据我所知，使用 enum 会:

• 实现更简单
• 不改变语法
• 允许在运行时更改参数(尽管在这种情况下不是很有用)。
• (可能)可以由编译器内联而不会影响性能

为什么标准库使用类型标签而不是 enum 来消除这些构造函数的歧义？也许更重要的是，我是否也应该更喜欢在此使用类型标签编写自己的 C++ 代码时的情况？

Answer 1

标签调度

这是一种称为标签调度的技术。它允许在给定客户端所需行为的情况下调用适当的构造函数。

标签的原因是标签使用的类型因此是不相关的，并且在重载解决期间不会发生冲突。类型(而不是枚举中的值)用于解析重载函数。此外，标签可用于解析原本不明确的调用；在这种情况下，标签通常基于某些类型特征。

使用模板进行标签调度意味着只需要实现给定构造需要使用的代码。

标签调度允许更容易阅读代码(至少在我看来)和更简单的库代码；构造函数不会有 switch 语句，并且在执行构造函数本身之前，可以根据这些参数在初始化列表中建立不变量。当然，您的里程可能会有所不同，但这是我使用标签的一般经验。

Boost.org有一篇关于标签调度技术的文章。它的使用历史似乎可以追溯到 at least as far as the SGI STL .

为什么要使用它？

Why does the standard library use type tags, instead of an enum, to disambiguate these constructors?

在重载决议和可能的实现过程中使用类型将比枚举更强大和灵活；请记住，枚举最初是无范围的，并且在使用方式上受到限制(与标签相反)。

标记的其他值得注意的原因；

• 编译时可以决定使用哪个构造函数，而不是运行时。
• 不允许使用更多“hacky”代码，其中将整数转换为具有未满足的值的枚举类型 - 需要制定设计决策来处理此问题，然后实现代码以适应任何导致的异常或错误.
• 请记住，shared_lock 和 lock_guard 也使用这些标签，但对于 lock_guard，只有 使用了adopt_lock。枚举会引入更多潜在的错误条件。

我认为优先级和历史在这里也发挥了作用。鉴于标准库和其他地方的广泛使用；它不太可能改变在库中实现情况(例如原始示例)的方式。

Perhaps more importantly, should I also prefer to use type tags in this situation when writing my own C++ code?

这本质上是一个设计决策。两者都可以而且应该用于针对他们解决的问题。我使用标签将数据和类型“路由”到正确的功能；特别是当实现在编译时不兼容并且有任何重载决议在起作用时。

标准库 std::advance 经常作为示例给出标签调度如何用于实现和优化基于所使用类型的特征(或特征)的算法(在此迭代器是随机访问迭代器的情况)。

如果使用得当，它是一种强大的技术，不应被忽视。如果使用枚举，请优先使用较新的范围枚举而不是较旧的无范围枚举。