This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofTC1 status.
Section: 31.5.2[ios.base]Status:TC1Submitter: Matt AusternOpened: 1998-06-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [ios.base].
View all issues withTC1 status.
Discussion:
As written, ios_base has a copy constructor and an assignmentoperator. (Nothing in the standard says it doesn't have one, and allclasses have copy constructors and assignment operators unless youtake specific steps to avoid them.) However, nothing in 27.4.2 sayswhat the copy constructor and assignment operator do.
My guess is that this was an oversight, that ios_base is, likebasic_ios, not supposed to have a copy constructor or an assignmentoperator.
Jerry Schwarz comments: Yes, its an oversight, but in the oppositesense to what you're suggesting. At one point there was a definiteintention that you could copy ios_base. It's an easy way to save theentire state of a stream for future use. As you note, to carry outthat intention would have required a explicit description of thesemantics (e.g. what happens to the iarray and parray stuff).
Proposed resolution:
In 31.5.2[ios.base], class ios_base, specify the copyconstructor and operator= members as being private.
Rationale:
The LWG believes the difficulty of specifying correct semanticsoutweighs any benefit of allowing ios_base objects to be copyable.