Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofResolved status.

889.thread::id comparisons

Section: 32.4.3.2[thread.thread.id]Status:ResolvedSubmitter: Lawrence CrowlOpened: 2008-09-15Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [thread.thread.id].

View all issues withResolved status.

Discussion:

Addresses UK 324

Thethread::id type supports the full set of comparison operators. Thisis substantially more than is required for the associative containers thatjustified 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 consideringsupport 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 paperN2723already hashash<thread::id>(22.10[function.objects], 22.10.19[unord.hash]). We simplyoverlooked 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 toconvertpthread_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 mentionhash< thread::id> norhash< error_code >, although their existence is implied by 22.10.19[unord.hash], p1.

I am fairly uncomfortable putting the declaration for thethread_id specialization into<functional> asid is a nested class insidestd::thread, so it impliesthat<functional> would require the definition of thethread class template in order to forward declaredthread::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 thehash<thread::id> specialization be declared in the<thread> header.

I thinkhash<error_code> could go into either<system_error> or<functional> and have noimmediate preference either way. However, it should clearly appear inthe 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 thatthread::id need not be a nested class;it could be atypedef for a more visible type.

[2009-05-24 Alisdair adds:]

I do not believe this is correct.thread::id is explicitly documents as anested class, rather than as an unspecified typedef analogous to aniterator. 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 threadheader. Alisdair to provide wording.

[2009-07-28 Alisdair provided wording, moved to Review.]

[2009-10 Santa Cruz:]

Add a strike forhash<thread::id>. Move to Ready

[2009-11-13 The proposed wording of1182⁽ⁱ⁾ is a superset of thewording in this issue.]

[2010-02-09 Moved from Ready to Open:]

Issue1182⁽ⁱ⁾ is not quite a superset of this issue and it is controversialwhether or not the note:

hash template specialization allowsthread::id objects to be used as keys inunordered containers.

should be added to the WP.

[2010-02-09 Objections to moving this toNAD EditorialResolved, addressed by1182⁽ⁱ⁾ have been removed. Set to TentativelyNAD EditorialResolved.]

Rationale:

Solved by1182⁽ⁱ⁾.

Proposed resolution:

Remove the following prototype from the synopsis in22.10[function.objects]:

template <> struct hash<std::thread::id>;

Add to 32.4[thread.threads], p1 Header<thread> synopsis:

template <class T> struct hash;template <> struct hash<thread::id>;

Add template specialization below class definition in 32.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 32.4.3.2[thread.thread.id] with second sentence:

[Note: Relational operators allowthread::id objects to be usedas keys in associative containers.hash template specialization allowsthread::id objects to be used as keysin unordered containers.—end note]

Add new paragraph to end of 32.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 typethread::id.