Section: 33.2.4 [thread.req.timing] Status: C++11 Submitter: LWG Opened: 2009-06-28 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [thread.req.timing].
View all issues with C++11 status.
Addresses UK 322, US 96
Not all systems can provide a monotonic clock. How are they expected to treat a _for function?
Add at least a note explaining the intent for systems that do not support a monotonic clock.
Create an issue, together with UK 96. Note that the specification as is already allows a non-monotonic clock due to the word “should” rather than “shall”. If this wording is kept, a footnote should be added to make the meaning clear.
[ 2009-06-29 Beman provided a proposed resolution. ]
[ 2009-10-31 Howard adds: ]
Set to Tentatively Ready after 5 positive votes on c++std-lib.
[ 2010-02-24 Pete moved to Open: ]
LWG 1158's proposed resolution replaces the ISO-specified normative term "should" with "are encouraged but not required to", which presumably means the same thing, but has no ISO normative status. The WD used the latter formulation in quite a few non-normative places, but only three normative ones. I've changed all the normative uses to "should".
[ 2010-03-06 Beman updates wording. ]
[ 2010 Pittsburgh: Moved to Ready. ]
Change Timing specifications 33.2.4 [thread.req.timing] as indicated:
The member functions whose names end in _for take an argument that specifies a relative time. Implementations should use a monotonic clock to measure time for these functions.