This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 33.4.3.2 [thread.thread.id] Status: Resolved Submitter: Lawrence Crowl Opened: 2008-09-15 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [thread.thread.id].
View all issues with Resolved status.
Discussion:
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> (22.10 [function.objects], 22.10.19 [unord.hash]). We simply overlooked it in the meeting. It is a good thing we voted in favor of it (again). :-)
Recommend NAD.
[ 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 22.10 [function.objects] does not mention hash< thread::id> nor hash< error_code >, although their existence is implied by 22.10.19 [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 EditorialResolved, addressed by 1182 have been removed. Set to Tentatively NAD EditorialResolved.
]
Rationale:
Solved by 1182.
Proposed resolution:
Remove the following prototype from the synopsis in 22.10 [function.objects]:
template <> struct hash<std::thread::id>;
Add to 33.4 [thread.threads], p1 Header <thread> synopsis:
template <class T> struct hash; template <> struct hash<thread::id>;
Add template specialization below class definition in 33.4.3.2 [thread.thread.id]
template <>
struct hash<thread::id> : public unary_function<thread::id, size_t> {
size_t operator()(thread::id val) const;
};
Extend note in p2 33.4.3.2 [thread.thread.id] with second sentence:
[Note: Relational operators allow thread::id objects to be used as keys in associative containers. hash template specialization allows thread::id objects to be used as keys in unordered containers. — end note]
Add new paragraph to end of 33.4.3.2 [thread.thread.id]
template <> struct hash<thread::id>;An explicit specialization of the class template hash (22.10.19 [unord.hash]) shall be provided for the type thread::id.