This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 31.7.7 [std.manip] Status: CD1 Submitter: Andy Sawyer Opened: 1999-07-07 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [std.manip].
View all issues with CD1 status.
Discussion:
31.7.7 [std.manip] paragraph 3 says (clause numbering added for exposition):
Returns: An object s of unspecified type such that if [1] out is an (instance of) basic_ostream then the expression out<<s behaves as if f(s) were called, and if [2] in is an (instance of) basic_istream then the expression in>>s behaves as if f(s) were called. Where f can be defined as: ios_base& f(ios_base& str, ios_base::fmtflags mask) { // reset specified flags str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression out<<s has type ostream& and value out. [4] The expression in>>s has type istream& and value in.
Given the definitions [1] and [2] for out and in, surely [3] should read: "The expression out << s has type basic_ostream& ..." and [4] should read: "The expression in >> s has type basic_istream& ..."
If the wording in the standard is correct, I can see no way of implementing any of the manipulators so that they will work with wide character streams.
e.g. wcout << setbase( 16 );
Must have value 'wcout' (which makes sense) and type 'ostream&' (which doesn't).
The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and 8. In addition, Para 6 [setfill] has a similar error, but relates only to ostreams.
I'd be happier if there was a better way of saying this, to make it clear that the value of the expression is "the same specialization of basic_ostream as out"&
Proposed resolution:
Replace section 31.7.7 [std.manip] except paragraph 1 with the following:
2- The type designated smanip in each of the following function descriptions is implementation-specified and may be different for each function.
smanip resetiosflags(ios_base::fmtflags mask);
-3- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves as if f(s, mask) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, mask) were called. The function f can be defined as:*
[Footnote: The expression cin >> resetiosflags(ios_base::skipws) clears ios_base::skipws in the format flags stored in the basic_istream<charT,traits> object cin (the same as cin >> noskipws), and the expression cout << resetiosflags(ios_base::showbase) clears ios_base::showbase in the format flags stored in the basic_ostream<charT,traits> object cout (the same as cout << noshowbase). --- end footnote]
ios_base& f(ios_base& str, ios_base::fmtflags mask)
{
// reset specified flags
str.setf(ios_base::fmtflags(0), mask);
return str;
}
The expression out<<s has type basic_ostream<charT,traits>& and value out. The expression in>>s has type basic_istream<charT,traits>& and value in.
smanip setiosflags(ios_base::fmtflags mask);
-4- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves as if f(s, mask) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, mask) were called. The function f can be defined as:
ios_base& f(ios_base& str, ios_base::fmtflags mask)
{
// set specified flags
str.setf(mask);
return str;
}
The expression out<<s has type basic_ostream<charT,traits>& and value out. The expression in>>s has type basic_istream<charT,traits>& and value in.
smanip setbase(int base);
-5- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves as if f(s, base) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, base) were called. The function f can be defined as:
ios_base& f(ios_base& str, int base)
{
// set basefield
str.setf(base == 8 ? ios_base::oct :
base == 10 ? ios_base::dec :
base == 16 ? ios_base::hex :
ios_base::fmtflags(0), ios_base::basefield);
return str;
}
The expression out<<s has type basic_ostream<charT,traits>& and value out. The expression in>>s has type basic_istream<charT,traits>& and value in.
smanip setfill(char_type c);
-6- Returns: An object s of unspecified type such that if out is (or is derived from) basic_ostream<charT,traits> and c has type charT then the expression out<<s behaves as if f(s, c) were called. The function f can be defined as:
template<class charT, class traits>
basic_ios<charT,traits>& f(basic_ios<charT,traits>& str, charT c)
{
// set fill character
str.fill(c);
return str;
}
The expression out<<s has type basic_ostream<charT,traits>& and value out.
smanip setprecision(int n);
-7- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves as if f(s, n) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, n) were called. The function f can be defined as:
ios_base& f(ios_base& str, int n)
{
// set precision
str.precision(n);
return str;
}
The expression out<<s has type basic_ostream<charT,traits>& and value out. The expression in>>s has type basic_istream<charT,traits>& and value in
.
smanip setw(int n);
-8- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves as if f(s, n) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, n) were called. The function f can be defined as:
ios_base& f(ios_base& str, int n)
{
// set width
str.width(n);
return str;
}
The expression out<<s has type basic_ostream<charT,traits>& and value out. The expression in>>s has type basic_istream<charT,traits>& and value in.
[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of the proposed resolution.]
[Tokyo - The LWG noted that issue 216 involves the same paragraphs.]
[Post-Tokyo: The issues list maintainer combined the proposed resolution of this issue with the proposed resolution for issue 216 as they both involved the same paragraphs, and were so intertwined that dealing with them separately appear fraught with error. The full text was supplied by Bill Plauger; it was cross checked against changes supplied by Andy Sawyer. It should be further checked by the LWG.]