Re: [boost] Re: Re: Re: Oughtn't filesystem::path acc ept the "*" and "?" wildcards?

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 
OSs
 >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 
library
 >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 
character-width, issues.

--Beman