为什么std :: this_thread命名空间？

Question

std :: this_thread名称空间是否存在技术原因？为什么这个命名空间的成员不能被实现为std :: thread类的静态成员？

Answer 1

从the original proposal开始，获取thread::id的方式拼写为get_id()，无论您是为自己获取thread::id，还是为子线程获取：{/ p>

  

请注意使用this_thread命名空间来消除歧义   请求当前线程的id，以及子线程的id。   此操作的get_id名称保持不变   减少界面的概念足迹。

std::thread my_child_thread(f);
typedef std::thread::id ID;

ID my_id = std::this_thread::get_id();  // The current thread's id
ID your_id = my_child_thread.get_id();  // The child   thread's id

因此，this_thread命名空间是一种区分二者的可读方式，同时将概念界面保持在最小值（获取线程ID的名称相同）。

这是一种可能的替代设计：

struct thread
{
    static int get_id() {return 1;}
    int get_id() const {return 2;}
};

这种设计的一个缺点是它不能编译：

test.cpp:4:9: error: static and non-static member functions with the same parameter types cannot be overloaded
    int get_id() const {return 2;}
        ^
test.cpp:3:16: note: previous declaration is here
    static int get_id() {return 1;}
               ^
1 error generated.

另一种设计会给静态成员一个不同的名称。但现在界面更大了。原始提案也以完全相同的方式处理了另一个功能：

bool have_i_been_canceled = std::this_thread::cancellation_requested();  // Current thread's cancellation status
bool have_you_been_canceled = my_child_thread.cancellation_requested();  // Child   thread's cancellation status

因此重用名称很有意义，因此客户不必学习这么多名字。如果他们想要查询当前线程，他们只需要学习使用this_thread命名空间。不幸的是，委员会在标准化过程中删除了线程取消。