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.3.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.