Title
string inserter not a formatted function
Status
cd1
Section
[string.io]
Submitter
Martin Sebor

Created on 2006-06-22.00:00:00 last changed 163 months ago

Messages

Date: 2010-10-21.18:28:33

Proposed resolution:

I propose to change the Effects clause in 21.3.7.9, p5, as follows:

Effects: Begins by constructing a sentry object k as if k were constructed by typename basic_ostream<charT, traits>::sentry k (os). If bool(k) is true, Behaves as a formatted output function (27.6.2.5.1). After constructing a sentry object, if this object returns true when converted to a value of type bool, determines padding as described in 22.2.2.2.2, then inserts the resulting sequence of characters seq as if by calling os.rdbuf()->sputn(seq , n), where n is the larger of os.width() and str.size(); then calls os.width(0). If the call to sputn fails, calls os.setstate(ios_base::failbit).

This proposed resilution assumes the resolution of issue 394 (i.e., that all formatted output functions are required to set ios_base::badbit in response to any kind of streambuf failure), and implicitly assumes that a return value of sputn(seq, n) other than n indicates a failure.

Date: 2006-06-22.00:00:00

Section and paragraph numbers in this paper are relative to the working draft document number N2009 from 4/21/2006.

The basic_string extractor in 21.3.7.9, p1 is clearly required to behave as a formatted input function, as is the std::getline() overload for string described in p7.

However, the basic_string inserter described in p5 of the same section has no such requirement. This has implications on how the operator responds to exceptions thrown from xsputn() (formatted output functions are required to set badbit and swallow the exception unless badbit is also set in exceptions(); the string inserter doesn't have any such requirement).

I don't see anything in the spec for the string inserter that would justify requiring it to treat exceptions differently from all other similar operators. (If it did, I think it should be made this explicit by saying that the operator "does not behave as a formatted output function" as has been made customary by the adoption of the resolution of issue 60).

History
Date User Action Args
2010-10-21 18:28:33adminsetmessages: + msg3143
2006-06-22 00:00:00admincreate