Revised 2013-10-14 at 15:10:23 UTC
Section: 30.4.1.3 [thread.timedmutex.requirements], 30.4.1.3.1 [thread.timedmutex.class] Status: Tentatively NAD Editorial Submitter: Vicente J. Botet Escriba Opened: 2012-01-01 Last modified: 2012-11-14
View all other issues in [thread.timedmutex.requirements].
View all issues with Tentatively NAD Editorial status.
Discussion:
30.4.1.3.1 [thread.timedmutex.class] says:
The class timed_mutex shall satisfy all of the TimedMutex requirements (30.4.1.3 [thread.timedmutex.requirements]). It shall be a standardlayout class (Clause 9 [class]).
Problem here is that 30.4.1.3 [thread.timedmutex.requirements] does not define a requirement set named "TimedMutex", it only refers to "timed mutex types"
[See also issue 2126]
[2012, Portland: move to Tentatively NAD Editorial]
We have timed mutex type, but it is labeled timed mutex requirements
We can make a suggestion, but will send to the editor as it seems purely editorial. There is a typo, and we don't have the timed mutex but 30.4.1.3 [thread.timedmutex.requirements] already says timed mutex type, and we need to reuse that term down in the class to fulfil the mutex requirement.
[To Editor:]
Replace this one with timed mutex type.
Proposed resolution:
Section: 30.4.1 [thread.mutex.requirements], 30.4.1.2.1 [thread.mutex.class], 30.4.1.2 [thread.mutex.requirements.mutex], 30.4.1.2.2 [thread.mutex.recursive], 30.4.1.3 [thread.timedmutex.requirements], 30.4.1.3.1 [thread.timedmutex.class], 30.4.1.3.2 [thread.timedmutex.recursive] Status: Tentatively NAD Editorial Submitter: Pete Becker Opened: 2012-01-16 Last modified: 2012-11-14
View all other issues in [thread.mutex.requirements].
View all issues with Tentatively NAD Editorial status.
Discussion:
30.4.1.2.1 [thread.mutex.class]/3 says that the class mutex "shall satisfy all the Mutex requirements (30.4.1 [thread.mutex.requirements])". 30.4.1.2.1 [thread.mutex.class] is part of 30.4.1 [thread.mutex.requirements], so at the very least, this requirement is recursive. But worse, there is nothing that says what "the Mutex requirements" refers to. For example, the "Lockable requirements" section starts with "A type L meets the Lockable requirements if …". There is no such statement for "the Mutex requirements".
Organizationally, paragraphs 1-26 in 30.4.1.2 [thread.mutex.requirements.mutex] should probably be in a subclause with a name. (This is actually an ISO requirement, to avoid exactly this kind of ambiguous referencing) Then the first sentence of 30.4.1.2.1 [thread.mutex.class]/3 can become a note: "The class mutex meets the requirements of (whatever)", since that subclause already says that the mutex types "shall meet the requirements set out in this section." And similarly for 30.4.1.2.2 [thread.mutex.recursive]/2 (recursive_mutex). 30.4.1.3 [thread.timedmutex.requirements], Timed mutex types, also needs the same rearrangement: its introductory requirements should be moved into a subclause, and the first sentences of 30.4.1.3.1 [thread.timedmutex.class]/2 and 30.4.1.3.2 [thread.timedmutex.recursive]/2 should be turned into notes that refer to this new subclause and to the new subclause in 30.4.1.2 [thread.mutex.requirements.mutex].[See also issue 2125]
[2012, Portland: move to Tentatively NAD Editorial]
Seems no real ambiguity. May need some reorg of text rather then changing the wording.
Is there much that needs to be changed? But Pete's suggestion of putting requirement in separate sub section is good. Should be the direction to editor.
Suggest this is an editorial change. Happy with Pete's comments.
Proposed resolution:
Section: 27.7.2.3 [istream.unformatted] Status: Tentatively NAD Submitter: Loïc Joly Opened: 2012-03-05 Last modified: 2013-05-21
View other active issues in [istream.unformatted].
View all other issues in [istream.unformatted].
View all issues with Tentatively NAD status.
Discussion:
I think the following code should be legal:
void f(std::istream& is) { std::string s; is.getline(s); // Would be equivalent to std::getline(is, s) }
[2013-04-20, Bristol]
Unanimous that this is a new feature request and not a issue.
Resolution: Tentatively NADProposed resolution:
This wording is relative to N3376.
Change the class template basic_istream synopsis, 27.7.2.1 [istream], as indicated
namespace std { template <class charT, class traits = char_traits<charT> > class basic_istream : virtual public basic_ios<charT,traits> { public: […] // 27.7.2.3 Unformatted input: […] basic_istream<charT,traits>& getline(char_type* s, streamsize n); basic_istream<charT,traits>& getline(char_type* s, streamsize n, char_type delim); template<class Allocator> basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str); template<class Allocator> basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str, char_type delim); […] }; }
Insert the following two new prototype descriptions after 27.7.2.3 [istream.unformatted] paragraph 24:
basic_istream<charT,traits>& getline(char_type* s, streamsize n);-24- Returns: getline(s,n,widen('\n'))
template<class Allocator> basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str);-??- Returns: std::getline(*this, str)
template<class Allocator> basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str, char_type delim);-??- Returns: std::getline(*this, str, delim)
Section: 30.4.1.2 [thread.mutex.requirements.mutex] Status: Tentatively NAD Editorial Submitter: Pete Becker Opened: 2012-03-05 Last modified: 2012-11-14
View other active issues in [thread.mutex.requirements.mutex].
View all other issues in [thread.mutex.requirements.mutex].
View all issues with Tentatively NAD Editorial status.
Discussion:
30.4.1.2 [thread.mutex.requirements.mutex]/11 says that prior unlock operations synchronize with m.lock().
30.4.1.2 [thread.mutex.requirements.mutex]/19 says that if m.try_lock() succeeds, prior unlock operations synchronize with the operation. 30.4.1.2 [thread.mutex.requirements.mutex]/25 says that m.unlock() synchronizes with subsequent successful lock operations. Does the third requirement add anything to the first two? If not, it should probably be a non-normative note.[2012, Portland: move to Tentatively NAD Editorial]
Agree that third note should be non-normative and adds nothing.
Seems An Editorial change, but does changing a normative to non-normative wording makes it a non-editorial change?
Ask the editor. If not editorial, then we will agree on the fix as removal of the third point, then we will put it in ready state for Bristol.
Proposed resolution:
Section: 24.5.1.3.4 [reverse.iter.op.star] Status: Tentatively NAD Submitter: David Abrahams Opened: 2012-10-30 Last modified: 2013-10-11
View all issues with Tentatively NAD status.
Discussion:
This note in 24.5.1.3.4 [reverse.iter.op.star]/2:
[ Note: This operation must use an auxiliary member variable rather than a temporary variable to avoid returning a reference that persists beyond the lifetime of its associated iterator. (See 24.2.) —end note ]
is incorrect because such iterator implementations are ruled out by 24.2.5 [forward.iterators]/6, where it says:
If a and b are both dereferenceable, then a == b if and only if *a and *b are bound to the same object.
[2013-04-20, Bristol]
Alisdair: sugested to strike the "exposition only" member.
Daniel: we must check that it wouldn't conflict with a previous solution to another issue. Dietmar: This is an issue but the proposing word is not correct. When we have proxies inside the sequence. Solution: NAD thanks to a contrieved example by Dietmar.Proposed resolution:
Strike the note, 24.5.1.3.4 [reverse.iter.op.star]/2:
[ Note: This operation must use an auxiliary member variable rather than a temporary variable to avoid returning a reference that persists beyond the lifetime of its associated iterator. (See 24.2.) —end note ]