POSIX 是否需要 `pthread_key_t`、`pthread_once_t` 和 `pthread_t` 的比较运算符？
sys/types.h 的标准文档 (https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html），说“以下类型没有定义的比较或赋值运算符：”，然后列出了一堆类型。但是，该列表中缺少一些非算术（或者不一定是算术）类型。值得注意的是，pthread_key_t、pthread_once_t 和 pthread_t 缺失。当非算术类型已经隐含“这些类型没有赋值和比较运算符”时，说“这些类型没有赋值和比较运算符”似乎很奇怪。这是否意味着一致的实现必须为这 3 种类型提供比较和赋值运算符？
The standards document for sys/types.h (https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html), says "There are no defined comparison or assignment operators for the following types:", then lists a bunch of types. However, some of the non-arithmetic (or rather not-necessarily arithmetic) types are missing from that list. Notably, pthread_key_t, pthread_once_t and pthread_t are missing. It seems odd to say "these types don't have assignment and comparison operators" when that's already implied for non-arithmetic types. Does this mean that conforming implementations must provide comparison and assignment operators for those 3 types?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
TL;DR：
pthread_key_t的比较或分配等可能有效也可能无效，具体取决于特定的 pthread 实现。pthread_mutex_t等的比较或赋值绝不能有效。不，这并不意味着符合要求的实现必须为这些类型提供比较或赋值运算符。事实上，如果实现将这些类型之一定义为结构，则无法提供比较运算符。 POSIX 基于 C 而不是 C++ 构建，并且 C 不允许对结构进行比较操作。
但是，使用结构不需要符合规范的实现。例如，如果他们选择的话，他们可以自由地使用算术类型。如果他们确实使用算术类型来定义
pthread_key_t、pthread_once_t或pthread_t之一，那么对该类型的比较和赋值操作可能是有效的。 （但是，如果应用程序想要可移植，则不应依赖它们）。例如，
pthread_mutex_t的情况并非如此。该标准没有指定如何定义pthread_mutex_t，因此理论上实现可以使用算术类型来定义pthread_mutex_t。然而，标准规定必须禁止 pthread_mutex_t 实例之间的比较和赋值操作。据推测，其原因类似于 C++ 标准不遗余力禁止复制
std::mutex实例的原因。复制互斥体是一个无意义的操作。对于标准禁止比较或赋值的大多数/所有其他类型也是如此。TL;DR: Comparison or assignment of
pthread_key_tand such may or may not be valid, depending on the particular pthreads implementation. Comparison or assignment ofpthread_mutex_tand such must never be valid.No, it doesn't mean that conforming implementations have to provide comparison or assignment operators for those types. In fact, if the implementation defines one of those types as a struct, a comparison operator would be impossible to provide. POSIX builds on C not C++, and C doesn't allow comparison operations on structs.
However, conforming implementations aren't required to use structs. If they chose to, they are free to use arithmetic types for example. If they did use an arithmetic type to define one of
pthread_key_t,pthread_once_torpthread_t, then comparison and assignment operations on that type would likely be valid. (However, an application shouldn't rely on them if it wants to be portable).This is not the case with
pthread_mutex_tfor example. The standard doesn't specify howpthread_mutex_tshould be defined, so an implementation could theoretically use an arithmetic type to definepthread_mutex_t. However, the standard is saying here that comparison and assignment operations between instances ofpthread_mutex_tmust be forbidden.Presumably the reasoning for this is similar to why the C++ standard goes out of it's way to forbid copying instances of
std::mutex. Copying a mutex is a nonsensical operation. The same is true for most/all of the other types the standard forbids comparison or assignment of.