[boost] [filesystem] i18n branch committed to CVS

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-03-23 10:07:22

CVS now contains a branch "i18n" of the filesystem directories:

* Class templates basic_path, basic_directory_iterator, etc, support 
narrow, wide, and user-defined path types. Typedefs path, 
directory_iterator, etc, are provided, so most existing code continues to 
work.

* Name checking has been moved out of class basic_path, so it no longer 
gets in the way of those not using the name checking facility. Deprecated 
versions of various functions are provided to preserve existing code.

* The need to explicitly identify native format paths via special 
constructors has been eliminated, simplifying casual use of the library. 
Deprecated versions of those constructors are provided to preserve existing 
code.

More detailed documentation is available in the i18n CVS branch at 
<boost-root>/libs/filesystem/doc/i18n.html. Most of the other documentation 
has also been updated to reflect the changes.

Current issues with the i18n branch include:

* Testing has been limited to Intel 8.1, Metrowerks 9.3, and Microsoft 7.1 
on Windows, and GCC 3.3 on Mac OS X. How much effort to put into broken 
compilers is going to be a real issue - internationalization may have to be 
disabled, and that is a lot of work.

* Some tests (particularly in operations_test.cpp) are commented out. Minor 
issues need to be resolved and the tests reactivated.

* Two or three of the less important doc files haven't been updated yet.

* The convenience header and source code hasn't been converted yet.

* The UTF-8 conversion facet header and source is duplicated. Need to 
identify and fix the issues that prevented the boost/detail version from 
being used.

* The "// TODO" notes in the code need to be revisited, issues fixed, and 
the notes eliminated.

* Testing on Windows 9X would be helpful, and issues fixed or documented.

* Backed up issues and patches from the mailing list need to be addressed.

* Windows tests need to be run on a FAT filesystem to see what issues 
arise. All of the Windows analysis and design effort so far has gone into 
NTFS, so there may be critical problems with filesystems that only support 
narrow paths.

* The POSIX wpath implementation assumes that UTF-8 is always the operating 
system's preferred external path encoding. If any Boost users are concerned 
about other encodings, please let me know.

* A timing test is needed, particularly for directory iteration. There is 
concern over excessive copying by basic_path conversion functions, so need 
to test if speed is a real problem in a realistic application.

Any comments would be appreciated (but please look at the docs first, as a 
lot of effort went into rationale and trying to answer anticipated 
questions).

My plan is to pause development for a while, both to allow time for 
comments to be made, and also so I can attack a backlog of non-Boost work 
that has been building up.

--Beman