使用std::thread::native_handle()，我可以在我的实现中获取底层的pthreads句柄（mingw-w64 with pthreads）
但有没有办法在预处理期间检查实现是否实际使用本机pthreads或其他东西（win32线程等等）？ 我想使代码尽可能便携，它将使用本机句柄来设置线程优先级。如果在编译期间不支持实现，则在编译时将禁用此功能。
但最重要的是，我想在构建配置或编译期间阻止以下情况：autoconf检测到pthreads，但实现不使用pthreads而是其他东西，并且我将错误的句柄传递给pthreads。
答案 0 :(得分：1)
没有什么可以说某个 MACRO 或等价物可用于预处理器（这会产生某个实现正在使用的线程实现）。
如果我们要检查std::thread::native_handler（std::thread::native_handle_type）的返回值（更具体地说是返回的类型），可能会认为它会产生更好的结果。
除了它对我们没有帮助之外，问题在于所述函数的返回类型是实现定义的;这意味着它可以返回任何东西，只要它恰好可以用作底层线程实现的句柄。
更糟糕的是;该函数可能根本不存在，如 [thread.req.native] 中所述：
30.2.3 / 1 原生句柄
[thread.req.native]p1本条款中描述的几个类都有成员
native_handle_type和native_handle。这些成员及其语义的存在是实现定义的。
查看与 pthreads 相关联的句柄，我们发现它是pthread_t - 此 type-id 通常是 typedef 表示内在类型unsigned long int。
如果我们深入了解win32线程库，我们会看到使用的句柄类型为HANDLE，（在更多挖掘之后）最终为void *。
即使我们可以实现，也可以假设 pthread_t “always”是一个整数类型，HANDLE “总是”归结为指向虚空的指针;没有这样的保证。
如果另一个线程实现也有unsigned long或void*作为其线程句柄，该怎么办？我们如何区分前两个？
总结一下;一个人不应该依赖std::thread::native_handler返回的类型来查询底层线程实现，因为没有什么可以说它将是一个独特的类型（跨越不同的线程实现）。
编写软件时不要依赖底层线程实现，只需使用std::thread并完成它。
如果{必须'拥有<thread>中没有的某些功能，则必须依赖一些外部魔法（例如 autoconf ）。