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.

### 454. `basic_filebuf::open` should accept `wchar_t` names

Section: 31.10.2.4 [filebuf.members] Status: NAD Submitter: Bill Plauger Opened: 2004-01-30 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [filebuf.members].

View all issues with NAD status.

Duplicate of: 105

Discussion:

        basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);

should be supplemented with the overload:

        basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);

Depending on the operating system, one of these forms is fundamental and the other requires an implementation-defined mapping to determine the actual filename.

[Sydney: Yes, we want to allow `wchar_t` filenames. Bill will provide wording.]

[ In Toronto we noted that this is issue 5 from N1569. ]

How does this interact with the newly-defined character types, and how do we avoid interface explosion considering `std::string` overloads that were added? Propose another solution that is different than the suggestion proposed by PJP.

Suggestion is to make a member template function for `basic_string` (for `char`, `wchar_t`, `u16char`, `u32char` instantiations), and then just keep a `const char*` member.

Goal is to do implicit conversion between character string literals to appropriate `basic_string` type. Not quite sure if this is possible.

Implementors are free to add specific overloads for non-char character types.

[ Martin adds pre-Sophia Antipolis: ]

> Please see issue 454: problems and solutions.

[ Sophia Antipolis: ]

> Beman is concerned that making these changes to `basic_filebuf` is not usefully changed unless `fstream` is also changed; this also only handles `wchar_t` and not other character types.

> The TR2 filesystem library is a more complete solution, but is not available soon.

[ Martin adds: please reference N2683 for problems and solutions. ]

Proposed resolution:

Change from:

>     basic_filebuf<charT,traits>* open(
>         const char* s,
>         ios_base::openmode mode );

> Effects: If is_open() != false, returns a null pointer. Otherwise, initializes the filebuf as required. It then opens a file, if possible, whose name is the NTBS s ("as if" by calling std::fopen(s,modstr)).

to:

>     basic_filebuf<charT,traits>* open(
>         const char* s,
>         ios_base::openmode mode );

>     basic_filebuf<charT,traits>* open(
>         const wchar_t* ws,
>         ios_base::openmode mode );

> Effects: If `is_open() != false`, returns a null pointer. Otherwise, initializes the `filebuf` as required. It then opens a file, if possible, whose name is the NTBS `s` ("as if" by calling `std::fopen(s,modstr)`). For the second signature, the NTBS `s` is determined from the WCBS `ws` in an implementation-defined manner.

> (NOTE: For a system that "naturally" represents a filename as a WCBS, the NTBS s in the first signature may instead be mapped to a WCBS; if so, it follows the same mapping rules as the first argument to open.)

Rationale:

Slightly controversial, but by a 7-1 straw poll the LWG agreed to move this to Ready. The controversy was because the mapping between wide names and files in a filesystem is implementation defined. The counterargument, which most but not all LWG members accepted, is that the mapping between narrow files names and files is also implemenation defined.

[Lillehammer: Moved back to "open" status, at Beman's urging. (1) Why just basic_filebuf, instead of also basic_fstream (and possibly other things too). (2) Why not also constructors that take std::basic_string? (3) We might want to wait until we see Beman's filesystem library; we might decide that it obviates this.]

[ post Bellevue: ]

> Move again to Ready.

> There is a timing issue here. Since the filesystem library will not be in C++0x, this should be brought forward. This solution would remain valid in the context of the proposed filesystem.

> This issue has been kicking around for a while, and the wchar_t addition alone would help many users. Thus, we suggest putting this on the reflector list with an invitation for someone to produce proposed wording that covers basic_fstream. In the meantime, we suggest that the proposed wording be adopted as-is.

> If more of the Lillehammer questions come back, they should be introduced as separate issues.

[ San Francisco: ]

> Some existing implementations provide overload already. Expected filesystem "path" object overloads neatly, without surprises; implying NAD.