This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 128. Need open_mode() function for file stream, string streams, file buffers, and string buffers

Section: 31.8 [string.streams], 31.10 [file.streams] Status: NAD Submitter: Angelika Langer Opened: 1999-02-22 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [string.streams].

View all issues with NAD status.

Discussion:

The following question came from Thorsten Herlemann:

> You can set a mode when constructing or opening a file-stream or filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get that mode later on, e.g. in my own operator << or operator >> or when I want to check whether a file-stream or file-buffer object passed as parameter is opened for input or output or binary? Is there no possibility? Is this a design-error in the standard C++ library?

It is indeed impossible to find out what a stream's or stream buffer's open mode is, and without that knowledge you don't know how certain operations behave. Just think of the append mode.

Both streams and stream buffers should have a `mode()` function that returns the current open mode setting.

[ post Bellevue: Alisdair requested to re-Open. ]

[ 2009-07 Frankfurt ]

> Neither Howard nor Bill has received a customer request for this.

> No consensus for change. The programmer can save this information to the side.

> Moved to NAD.

Proposed resolution:

For stream buffers, add a function to the base class as a non-virtual function qualified as const to 31.6.3 [streambuf]:

`openmode mode() const`;

Returns the current open mode.

With streams, I'm not sure what to suggest. In principle, the mode could already be returned by `ios_base`, but the mode is only initialized for file and string stream objects, unless I'm overlooking anything. For this reason it should be added to the most derived stream classes. Alternatively, it could be added to `basic_ios` and would be default initialized in `basic_ios<>::init()`.

Rationale:

This might be an interesting extension for some future, but it is not a defect in the current standard. The Proposed Resolution is retained for future reference.