Frequently Asked Questions</h1>
<h2>General questions</h2>
<p><b>Why not support a concept of specific kinds of file systems, such as posix_file_system or windows_file_system.</b></p>
-<p>Portability is one of the most important requirements for the
-library. Features specific to a particular operating system or file system
+<p>Portability is one of the most important requirements for the
+library. Features specific to a particular operating system or file system
can always be accessed by using the operating system's API.</p>
<h2>
Class <code><font size="6">path</font></code> questions </h2>
<p><b>Why base the generic pathname format on POSIX?</b></p>
-<p><a href="design.htm#POSIX-01">POSIX</a> is an ISO Standard. It is the basis for the most familiar
-pathname formats,
-not just for POSIX-based operating systems but also for Windows and the
-URL portion of URI's. It is ubiquitous and
-familiar. On many systems, it is very easy to implement because it is
-either the native operating system format (Unix and Windows) or via an
-operating system supplied
+<p><a href="design.htm#POSIX-01">POSIX</a> is an ISO Standard. It is the basis for the most familiar
+pathname formats,
+not just for POSIX-based operating systems but also for Windows and the
+URL portion of URI's. It is ubiquitous and
+familiar. On many systems, it is very easy to implement because it is
+either the native operating system format (Unix and Windows) or via an
+operating system supplied
POSIX library (z/OS, OS/390, and many more.)</p>
<p><b>Why not use a full URI (Universal Resource Identifier) based path?</b></p>
-<p><a href="design.htm#URI">URI's</a> would promise more than the Filesystem Library can actually deliver,
-since URI's extend far beyond what most operating systems consider a file or a
-directory. Thus for the primary "portable script-style file system
+<p><a href="design.htm#URI">URI's</a> would promise more than the Filesystem Library can actually deliver,
+since URI's extend far beyond what most operating systems consider a file or a
+directory. Thus for the primary "portable script-style file system
operations" requirement of the Filesystem Library, full URI's appear to be over-specification.</p>
<p><b>Why isn't <i>path</i> a base class with derived <i>directory_path</i> and
<i>file_path</i> classes?</b></p>
-<p>Why bother? The behavior of all three classes is essentially identical.
-Several early versions did require users to identify each path as a file or
-directory path, and this seemed to increase coding errors and decrease code
+<p>Why bother? The behavior of all three classes is essentially identical.
+Several early versions did require users to identify each path as a file or
+directory path, and this seemed to increase coding errors and decrease code
readability. There was no apparent upside benefit.</p>
-<p><b>Why do path decomposition functions yielding a single element return a
+<p><b>Why do path decomposition functions yielding a single element return a
path rather than a string?</b></p>
<p>Interface simplicity. If they returned strings, flavors would be needed for
<code>string</code>, <code>wstring</code>, <code>u16string</code>, <code>
u32string</code>, and generic strings.</p>
<p><b>Why don't path member functions have overloads with error_code& arguments?</b></p>
-<p>They have not been requested by users; the need for error reporting via
+<p>They have not been requested by users; the need for error reporting via
error_code seems limited to operations failures rather than path failures.</p>
<h2>Operations function questions</h2>
-<p><b>Why not supply a 'handle' type, and let the file and directory operations
+<p><b>Why not supply a 'handle' type, and let the file and directory operations
traffic in it?</b></p>
-<p>It isn't clear there is any feasible way to meet the "portable script-style
-file system operations" requirement with such a system. File systems exist where operations are usually performed on
- some non-string handle type. The classic Mac OS has been mentioned explicitly as a case where
+<p>It isn't clear there is any feasible way to meet the "portable script-style
+file system operations" requirement with such a system. File systems exist where operations are usually performed on
+ some non-string handle type. The classic Mac OS has been mentioned explicitly as a case where
trafficking in paths isn't always natural. </p>
-<p>The case for the "handle" (opaque data type to identify a file)
-style may be strongest for directory iterator value type. (See Jesse Jones' Jan 28,
-2002, Boost postings). However, as class path has evolved, it seems sufficient
+<p>The case for the "handle" (opaque data type to identify a file)
+style may be strongest for directory iterator value type. (See Jesse Jones' Jan 28,
+2002, Boost postings). However, as class path has evolved, it seems sufficient
even as the directory iterator value type.</p>
<p><b>Why are the operations functions so low-level?</b></p>
<p>To provide a toolkit from which higher-level functionality can be created.</p>
-<p>An
-extended attempt to add convenience functions on top of, or as a replacement
-for, the low-level functionality failed because there is no widely acceptable
-set of simple semantics for most convenience functions considered.
-Attempts to provide alternate semantics via either run-time options or
-compile-time polices became overly complicated in relation to the value
-delivered, or became contentious. OTOH, the specific functionality needed for several trial
-applications was very easy for the user to construct from the lower-level
-toolkit functions. See <a href="design.htm#Abandoned_Designs">Failed
+<p>An
+extended attempt to add convenience functions on top of, or as a replacement
+for, the low-level functionality failed because there is no widely acceptable
+set of simple semantics for most convenience functions considered.
+Attempts to provide alternate semantics via either run-time options or
+compile-time polices became overly complicated in relation to the value
+delivered, or became contentious. OTOH, the specific functionality needed for several trial
+applications was very easy for the user to construct from the lower-level
+toolkit functions. See <a href="design.htm#Abandoned_Designs">Failed
Attempts</a>.</p>
<p><b>Isn't it inconsistent then to provide a few convenience functions?</b></p>
-<p>Yes, but experience with both this library, POSIX, and Windows, indicates
-the utility of certain convenience functions, and that it is possible to provide
+<p>Yes, but experience with both this library, POSIX, and Windows, indicates
+the utility of certain convenience functions, and that it is possible to provide
simple, yet widely acceptable, semantics for them. For example, <code>remove_all()</code>.</p>
-<p><b>Why are there directory_iterator overloads for operations.hpp
+<p><b>Why are there directory_iterator overloads for operations.hpp
predicate functions? Isn't two ways to do the same thing poor design?</b></p>
-<p>Yes, two ways to do the same thing is often a poor design practice. But the
-iterator versions are often much more efficient. Calling status() during
-iteration over a directory containing 15,000 files took 6 seconds for the path
-overload, and 1 second for the iterator overload, for tests on a freshly booted
-machine. Times were .90 seconds and .30 seconds, for tests after prior use of
-the directory. This performance gain is large enough to justify deviating from
+<p>Yes, two ways to do the same thing is often a poor design practice. But the
+iterator versions are often much more efficient. Calling status() during
+iteration over a directory containing 15,000 files took 6 seconds for the path
+overload, and 1 second for the iterator overload, for tests on a freshly booted
+machine. Times were .90 seconds and .30 seconds, for tests after prior use of
+the directory. This performance gain is large enough to justify deviating from
preferred design practices. Neither overload alone meets all needs.</p>
<p><b>Why are the operations functions so picky about errors?</b></p>
-<p>Safety. The default is to be safe rather than sorry. This is particularly
-important given the reality that on many computer systems files and directories
-are globally shared resources, and thus subject to
+<p>Safety. The default is to be safe rather than sorry. This is particularly
+important given the reality that on many computer systems files and directories
+are globally shared resources, and thus subject to
race conditions.</p>
<p><b>Why are attributes accessed via named functions rather than property maps?</b></p>
-<p>For commonly used attributes (existence, directory or file, emptiness),
-simple syntax and guaranteed presence outweigh other considerations. Because
-access to many other attributes is inherently system dependent,
-property maps are viewed as the best hope for access and modification, but it is
-better design to provide such functionality in a separate library. (Historical
-note: even the apparently simple attribute "read-only" turned out to be so
+<p>For commonly used attributes (existence, directory or file, emptiness),
+simple syntax and guaranteed presence outweigh other considerations. Because
+access to many other attributes is inherently system dependent,
+property maps are viewed as the best hope for access and modification, but it is
+better design to provide such functionality in a separate library. (Historical
+note: even the apparently simple attribute "read-only" turned out to be so
system depend as to be disqualified as a "guaranteed presence" operation.)</p>
<p><b>Why isn't automatic name portability error detection provided?</b></p>
-<p>A number (at least six) of designs for name validity error
-detection were evaluated, including at least four complete implementations.
-While the details for rejection differed, all of the more powerful name validity checking
-designs distorted other
-otherwise simple aspects of the library. Even the simple name checking provided
-in prior library versions was a constant source of user complaints. While name checking can be helpful, it
+<p>A number (at least six) of designs for name validity error
+detection were evaluated, including at least four complete implementations.
+While the details for rejection differed, all of the more powerful name validity checking
+designs distorted other
+otherwise simple aspects of the library. Even the simple name checking provided
+in prior library versions was a constant source of user complaints. While name checking can be helpful, it
isn't important enough to justify added a lot of additional complexity.</p>
-<p><b>Why are paths sometimes manipulated by member functions and sometimes by
+<p><b>Why are paths sometimes manipulated by member functions and sometimes by
non-member functions?</b></p>
-<p>The design rule is that purely lexical operations are supplied as <i>class
-path</i> member
-functions, while operations performed by the operating system are provided as
+<p>The design rule is that purely lexical operations are supplied as <i>class
+path</i> member
+functions, while operations performed by the operating system are provided as
free functions.</p>
<hr>
<p>Revised
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->29 December, 2014<!--webbot bot="Timestamp" endspan i-checksum="38652" --></p>
<p>© Copyright Beman Dawes, 2002</p>
-<p> Use, modification, and distribution are subject to the Boost Software
+<p> Use, modification, and distribution are subject to the Boost Software
License, Version 1.0. See <a href="http://www.boost.org/LICENSE_1_0.txt">
-www.boost.org/LICENSE_1_0.txt</a></p>
\ No newline at end of file
+www.boost.org/LICENSE_1_0.txt</a></p>
+</body>
+</html>
projects / platform / upstream / boost.git / blobdiff