--- f:\temp\i18n_1.2.2.1_0.html 2007-06-03 17:15:45.000000000 -0400 +++ C:\boost\site\libs\filesystem\doc\i18n.html 2007-06-03 16:41:28.000000000 -0400 @@ -34,13 +34,14 @@
Rationale for some of the changes is also provided.
Cass templates basic_path, basic_filesystem_error, and basic_directory_iterator provide the basic mechanisms for @@ -64,16 +65,16 @@ types is performed by path traits classes. The specific conversions for path and wpath is implementation defined, with normative encouragement to use the operating system's preferred file system encoding. For many modern POSIX-based file systems the wpath external encoding is UTF-8, while for modern Windows file systems such as NTFS it is UTF-16.
-The operational functions in +
The operational functions in operations.hpp are provided with overloads for path, wpath, and user-defined basic_path's. A -"do-the-right-thing" rule +"do-the-right-thing" rule applies to implementations, ensuring that the correct overload will be chosen.
Prior versions of the library required users of class path to identify
the format (native or generic) and name error-checking policy, either via a
second constructor argument or via a default mechanism. That approach caused
complaints, particularly from users not needing the name checking features. The
@@ -85,13 +86,14 @@
These constructors are only provided to ease the transition of existing code.
Additionally, basic_filesystem_error has been put +
Additionally, +basic_filesystem_error has been put on a diet and generally simplified.
Error codes have been simplified and aligned with [POSIX-01]. A supporting header <boost/filesystem/cerrno.hpp> is also provided.
"//:"
has been introduced as a path escape prefix to identify
native paths. Rationale: simplifies basic_path constructor interfaces, easier
@@ -107,33 +109,33 @@
what the expectations were for true and false values of the various predicates.
See the table below.
As part of the predicate discussions, particularly with Rob Stewart, it became obvious that sometimes applications need access to raw status information without any possibility of an exception being thrown. The -status() function was added to meet this +status() function was added to meet this need. It also proved clearer to specify the semantics of predicate functions in terms of status().
About the same time, Jeff Garland suggested that an -is_file() predicate would -compliment -is_directory(). In working on the analysis below, it became obvious +is_file() predicate would +compliment is_directory(). In working on the analysis below, it became obvious that the expectations for is_file() were different from the expectations for !is_directory(), so is_file() was added.
On some operating systems, it is possible to have a directory entry which is -not for either a directory or a file. The is_other() +not for either a directory or a file. The +is_other() function identifies such cases.
Some conditions reported by operating systems as errors (see footnote) clearly simply indicate that the predicate is false, rather than indicating serious failure. But other errors represent serious hardware or network problems, or permissions problems.
Some people, particularly Rob Stewart, argue that in a function like -is_directory(), any error should simply cause the function to return false. If +is_directory(), any error should simply cause the function to return false. If there is actually an underlying problem, it will be detected it due course when a directory_iterator or fstream operation is attempted.
That view is was rejected because of the following considerations:
The rationale for not including versions of status() which throw exceptions on errors is that (1) the primary purpose of this function is to perform queries at a very low-level, where exceptions are usually unwanted, and (2) exceptions on errors are already provided by the predicate functions. There would be little or no efficiency gain from providing a throwing version of status().
-A symlink identifying version of the status() function is distinguished by a second argument. Often separately named functions are more appropriate than overloading when behavior differs, which is the case here, while overloads are more appropriate when behavior is the same but argument types differ (Iain Hanson). Overloading was chosen in this particular case because a subjective judgment that a single @@ -412,15 +414,15 @@ characters, the default conversion should not depend on the operating system alone, but on the std::locale("") default. For example, the usual encoding for Russian on Linux (and Russian web sites) is KOI8-R (RFC1489). The ability to safely specify a different locale is also provided, to meet unforeseen needs.
Revised -16 December, 2005
+03 June, 2007© Copyright Beman Dawes, 2005
Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at www.boost.org/LICENSE_1_0.txt)