Section: 18.104.22.168 [thread.thread.id] Status: Resolved Submitter: Lawrence Crowl Opened: 2008-09-15 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [thread.thread.id].
View all issues with Resolved status.
Addresses UK 324
The thread::id type supports the full set of comparison operators. This is substantially more than is required for the associative containers that justified them. Please place an issue against the threads library.
[ San Francisco: ]
Would depend on proposed extension to POSIX, or non-standard extension. What about hash? POSIX discussing op. POSIX not known to be considering support needed for hash, op.
Group expresses support for putting ids in both unordered and ordered containers.
[ post San Francisco: ]
Howard: It turns out the current working paper N2723 already has hash<thread::id> (23.14 [function.objects], 23.14.15 [unord.hash]). We simply overlooked it in the meeting. It is a good thing we voted in favor of it (again). :-)
[ Post Summit: ]
Recommend to close as NAD. For POSIX, see if we need to add a function to convert pthread_t to integer.
[ Post Summit, Alisdair adds: ]
The recommendation for LWG-889/UK-324 is NAD, already specified.
It is not clear to me that the specification is complete.
In particular, the synopsis of <functional> in 23.14 [function.objects] does not mention hash< thread::id> nor hash< error_code >, although their existence is implied by 23.14.15 [unord.hash], p1.
I am fairly uncomfortable putting the declaration for the thread_id specialization into <functional> as id is a nested class inside std::thread, so it implies that <functional> would require the definition of the thread class template in order to forward declared thread::id and form this specialization.
It seems better to me that the dependency goes the other way around (<thread> will more typically make use of <functional> than vice-versa) and the hash<thread::id> specialization be declared in the <thread> header.
I think hash<error_code> could go into either <system_error> or <functional> and have no immediate preference either way. However, it should clearly appear in the synopsis of one of these two.
Recommend moving 889 back to open, and tying in a reference to UK-324.
[ Batavia (2009-05): ]
Howard observes that thread::id need not be a nested class; it could be a typedef for a more visible type.
[ 2009-05-24 Alisdair adds: ]
I do not believe this is correct. thread::id is explicitly documents as a nested class, rather than as an unspecified typedef analogous to an iterator. If the intent is that this is not implemented as a nested class (under the as-if freedoms) then this is a novel form of standardese.
[ 2009-07 Frankfurt ]
Decided we want to move hash specialization for thread_id to the thread header. Alisdair to provide wording.
[ 2009-07-28 Alisdair provided wording, moved to Review. ]
[ 2009-10 Santa Cruz: ]
Add a strike for hash<thread::id>. Move to Ready
[ 2009-11-13 The proposed wording of 1182 is a superset of the wording in this issue. ]
[ 2010-02-09 Moved from Ready to Open: ]
Issue 1182 is not quite a superset of this issue and it is controversial whether or not the note:
hash template specialization allows thread::id objects to be used as keys in unordered containers.
should be added to the WP.
2010-02-09 Objections to moving this to
NAD Editorial, addressed by 1182 have been removed. Set to Tentatively NAD Editorial.
Solved by 1182.
Remove the following prototype from the synopsis in 23.14 [function.objects]:
template <> struct hash<std::thread::id>;
Add to 33.3 [thread.threads], p1 Header <thread> synopsis:
Add template specialization below class definition in 22.214.171.124 [thread.thread.id]
Extend note in p2 126.96.36.199 [thread.thread.id] with second sentence:
[Note: Relational operators allow thread::id objects to be used as keys in associative containers. — end note]
Add new paragraph to end of 188.8.131.52 [thread.thread.id]