This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofTC1 status.
Section: 29.4.6[complex.ops]Status:TC1Submitter: Angelika LangerOpened: 1999-05-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [complex.ops].
View all issues withTC1 status.
Discussion:
The extractor for complex numbers is specified as:
template<class T, class charT, class traits>
basic_istream<charT, traits>&
operator>>(basic_istream<charT, traits>& is, complex<T>& x);
Effects: Extracts a complex number x of the form: u, (u), or (u,v),where u is the real part and v is the imaginary part(lib.istream.formatted).
Requires: The input values be convertible to T. If bad input isencountered, calls is.setstate(ios::failbit) (which may throwios::failure (lib.iostate.flags).
Returns: is .
Is it intended that the extractor for complex numbers does not skipwhitespace, unlike all other extractors in the standard library do?Shouldn't a sentry be used?
The inserter for complex numbers is specified as:
template<class T, class charT, class traits>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);
Effects: inserts the complex number x onto the stream o as if it were implemented as follows:
template<class T, class charT, class traits>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x)
{
basic_ostringstream<charT, traits> s;
s.flags(o.flags());
s.imbue(o.getloc());
s.precision(o.precision());
s << '(' << x.real() << "," << x.imag() << ')';
return o << s.str();
}
Is it intended that the inserter for complex numbers ignores thefield width and does not do any padding? If, with the suggestedimplementation above, the field width were set in the stream then theopening parentheses would be adjusted, but the rest not, because thefield width is reset to zero after each insertion.
I think that both operations should use sentries, for sake ofconsistency with the other inserters and extractors in thelibrary. Regarding the issue of padding in the inserter, I don't knowwhat the intent was.
Proposed resolution:
After 29.4.6[complex.ops] paragraph 14 (operator>>), add aNotes clause:
Notes: This extraction is performed as a series of simplerextractions. Therefore, the skipping of whitespace is specified to be thesame for each of the simpler extractions.
Rationale:
For extractors, the note is added to make it clear that skipping whitespacefollows an "all-or-none" rule.
For inserters, the LWG believes there is no defect; the standard is correctas written.