From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-04-22 19:29:10
At 09:03 PM 4/21/2003, Edward Diener wrote:
>Beman Dawes wrote:
>> Once the portable case is handled, then I'm willing to see if native
>> format paths with wild-cards can be accommodated. But solving the
>> portable case seems to me to be most important.
>I can see the theoretical importance of a portable regex-based filter but
>the practical importance of providing non-portable filters for specific
>in the filesystem library.
Well, if you think it is that important, why don't you try to come up with
a specific proposed solution? That's much more likely to result in action
than just urging other people to do the work. The solution would have to
have a portable grammar, plus at least the Windows and POSIX wild-card
grammars. There would have to be specification of which functions support
wild cards, and a bunch of portable, Windows, and POSIX test cases.
>> My highest current priority for filesystem is work on
>> internationalization, specifically portable wide-character paths.
>> Until that problem is solved,
>> the filesystem library can't be proposed for standardization.
>Since I was very vocal on this issue on comp.std.c++, I would really like
>to know what happens regarding wide-character file names in the future. I
>believe very strongly that the next iteration of the C++ standard library
>needs to support wide-character file names,
People have been saying that for years, but it has only been in the last
six months that concrete proposals are starting to surface. So far they
appear to conflict, but I'm working to try to resolve those conflicts.
> and that it does no good for the
>C++ committee to avoid this issue and hope it just fades away somehow.
You've been misinformed is someone has said that the committee hopes the
issue will fade away. Much serious internationalization work is done by
members of the various standards committees, and they care deeply about
internationalization. The C committee is working on a TR right now whose
main purpose is to ease ISO 10646/Unicode usage. Presumably similar
functionality will also become part C++ in due time.
> I do
>not believe that C++ should attempt to legislate what wide characters go
>into a wide character file name as different locales will have their own
>idea of what constitutes a valid wide character name.
Operating system and program interoperability requirements drive the
character validity, encoding, and conversion specifications. That doesn't
leave much room for either the C++ standard or user supplied
specifications. For example, if an operating system function rejects a
path as being invalid, there is nothing either the C++ standard or the user
can do about it.
> Neverthless I am
>willing to be wrong about this as long as the C++ standards commitee
>realizes that it is important to add to the C++ standard library wide
>character filename support of some kind, so that cultures whose normal
>language encoding is a wide character one can use the C++ standard
>to specify wide character names for their I/O functionality on OSs which
>support wide character filenames.
Remember that the C++ committee includes active long-time members from
Japan, and that as one of the ten or twelve voting delegations to the WG21
ISO portion of the committee, their views carry a great deal of weight.
Even if everyone else is asleep, the Japanese delegation will politely
remind us of the importance of internationalization, and particularly
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk