Beman Dawes wrote:
At 04:06 PM 2/15/2004, David Abrahams wrote:
"Edward Diener" <eddielee@tropicsoft.com> writes:
the C++ standard committee is so intent on not supporting wide character filenames
Be careful about your generalizations. I doubt you've polled the standard committee's members or have any good idea about their intention in this matter.
Exactly.
It sounds like Edward has been talking to a C++ standards committee from a parallel universe.
I don't think this sort of put-down is necessary. I can get just as clever, or nasty, in attempting to put you down on this NG, but I don't think cleverness or nastiness is worth much compared to thought and creativity. If you think I am lying, just say so. While I respect your talents as a programmer, they don't warrant arrogance when dealing with others who have a different opinion than you do. I have never talked to a C++ standards committee, nor have claimed to. I did converse with more than one committee member about this issue on comp.std.c++. If that is what your statement above is supposed to mean, I can assure you that the parallel universe is a real one and it is ours. Regarding the C++ standards committee not being in favor of wide character filenames, I quote from your own FAQ on filesystem. "The C++ standards committee Library Working Group discussed this in some detail both on the committee's library reflector and at the Spring, 2002, meeting, and feels that (1) names based on types other than char are extremely non-portable, (2) there are no agreed upon semantics for conversion between wide-character and narrow-character names for file systems which do not support wide-character name, and (3) even the committee members most interested in wide-character names are unsure that they are a good idea in the context of a portable library." I interpret this to mean that the commitee was not in favor of adding wide character file name support to the C++ standard library. In my discussions on comp.std.c++, particularly with Mr. Plauger, I was more or less told that the committee had already made up its mind not to support wide character file names. He was pretty intolerant to the thought that wide character file names should be added with the proviso that their meaning should be implementation defined. I tried to argue that narrow character file names are implementation defined, since nowhere that I have ever found in the C++ standard document is there any meaning placed on the sequence of chars which make up a narrow character file name, but he didn't believe that this argument was substantive. BTW I wasn't the only one presenting an opinion that wide character file names should be added to the C++ standard library basic_fstream classes. I do realize that you subsequently write that "[October, 2002 - PJ Plauger has suggested a locale based conversion scheme. Others have indicated support for such an experiment.]" As far as you filesystem library is concerned, I believe the issue is very different. You have rightly attempted to come up with a portable syntax for file names, and adding wide character file name support would mean that the issue of a syntax for such a file name, and its meaning and operation on operating systems or implementations which don't support wide character file names, has to be decided by your library.
The C++ committee from this universe has never had a proposal before it to support wide-character filenames.
I never claimed they did. But since they essentially made up their mind against it, or indicated support for a locale based conversion scheme, I didn't pursue any further attempts to argue for my own opionion, or submit a proposal for it.
The LWG has never even formally discussed what path internationalization might look like, AFAICR, although there has been occasional informal discussion between members. Several LWG members are interested in finding solutions to the issues raised by the internationalization of paths, and have contributed support and ideas to Boost.Filesystem's internationalization.
I think that is great but my comments were not intended to be about the internationalization of paths but rather about support for wide character file names in the C++ standard library basic_fstream class ( and message facet ). IMHO these are two separate issues, but I can understand if others disagree and view them as the same issue.