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.
Section: 22.214.171.124 [filebuf.members] Status: NAD Submitter: Bill Plauger Opened: 2004-01-30 Last modified: 2016-12-23
Priority: Not Prioritized
View all other issues in [filebuf.members].
View all issues with NAD status.
Duplicate of: 105
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. ]
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)).
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.)
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.