Is there a technical reason for the std::this_thread namespace? Why could the members of this namespace not have been implemented as static members of the std::thread class?
1 Answers
From the original proposal, the way to get a thread::id
is spelled get_id()
whether you are getting the thread::id
for yourself, or for a child thread:
Note the use of the
this_thread
namespace to disambiguate when you are requesting the id for the current thread, vs the id of a child thread. Theget_id
name for this action remains the same in the interest of reducing the conceptual footprint of the interface.
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
Thus the this_thread
namespace is a readable way to differentiate between the two, while keeping the conceptual interface to a minimum (same name for getting a thread id).
Here's a possible alternative design:
struct thread
{
static int get_id() {return 1;}
int get_id() const {return 2;}
};
One disadvantage of this design is that it does not compile:
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.
Another design would have given the static member a different name. But now the interface is bigger. The original proposal also treated another function the exact same way:
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
Thus it made a lot of sense to reuse the names so clients don't have to learn so many names. They just need to learn to use the this_thread
namespace if they want to query the current thread. Unfortunately the committee removed thread cancellation during standardization.

- 20,807
- 5
- 72
- 86

- 206,506
- 52
- 449
- 577
-
Thanks, but how could my_child_thread.get_id() ever be ambiguous? I guess I am looking for a real-life example here. Which I know is a lot to ask. – Feb 22 '13 at 21:23
-
@user2100815 Well, not so much ambiguous as "not working". If `get_id` is the `static` member function to get the current thread's ID, `my_child_thread.get_id()` calls that static member function. See http://codepad.org/JRTvzDLk for a simplified example. (By the way, I didn't come up with this myself, someone has written this in a comment an hour ago!) – Feb 22 '13 at 21:39
-
1@user2100815 give us an example of how else you would do it. – Seth Carnegie Feb 22 '13 at 21:41
-
@Seth You seem to think I am criticising the standard library. On the contrary, I'm trying to understand it. – Feb 22 '13 at 21:52
-
3@user2100815 I know you are, and if you think I'm criticising you, you are mistaken. I am trying to understand it too. I'm just offering my opinion, which is worth less than the bytes it's encoded in, that's all. When I asked for an example from you, I wanted one because you asked how it could be ambiguous, which it can't be unless you decide to do it another way. – Seth Carnegie Feb 22 '13 at 21:55