4

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?

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467

1 Answers1

15

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. The get_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.

Rapptz
  • 20,807
  • 5
  • 72
  • 86
Howard Hinnant
  • 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