Title
Lack of const-qualification in clause 27
Status
cd1
Section
[input.output]
Submitter
Walter Brown, Marc Paterno

Created on 2002-05-10.00:00:00 last changed 171 months ago

Messages

Date: 2010-10-21.18:28:33

Rationale:

Of the changes proposed in N1360, the only one that is safe is changing the filestreams' is_open to const. The LWG believed that this was NAD the first time it considered this issue (issue 73), but now thinks otherwise. The corresponding streambuf member function, after all,is already const.

The other proposed changes are less safe, because some streambuf functions that appear merely to report a value do actually perform mutating operations. It's not even clear that they should be considered "logically const", because streambuf has two interfaces, a public one and a protected one. These functions may, and often do, change the state as exposed by the protected interface, even if the state exposed by the public interface is unchanged.

Note that implementers can make this change in a binary compatible way by providing both overloads; this would be a conforming extension.

Date: 2010-10-21.18:28:33

Proposed resolution:

In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13

Replace

  bool is_open();

with

  bool is_open() const;
Date: 2002-05-10.00:00:00

Some stream and streambuf member functions are declared non-const, even thought they appear only to report information rather than to change an object's logical state. They should be declared const. See document N1360 for details and rationale.

The list of member functions under discussion: in_avail, showmanyc, tellg, tellp, is_open.

Related issue: 73

History
Date User Action Args
2010-10-21 18:28:33adminsetmessages: + msg2368
2010-10-21 18:28:33adminsetmessages: + msg2367
2002-05-10 00:00:00admincreate