bb7dc550d5
Boost.Filesystem does not support char16_t and char32_t yet, so don't document related types and APIs in the docs. Related to https://github.com/boostorg/filesystem/issues/86.
149 lines
8.3 KiB
HTML
149 lines
8.3 KiB
HTML
<html>
|
|
|
|
<head>
|
|
<meta http-equiv="Content-Language" content="en-us">
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<title>Filesystem FAQ</title>
|
|
<link href="styles.css" rel="stylesheet">
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<table border="0" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111">
|
|
<tr>
|
|
<td width="277">
|
|
<a href="../../../index.htm">
|
|
<img src="../../../boost.png" alt="boost.png (6897 bytes)" align="middle" width="300" height="86" border="0"></a></td>
|
|
<td align="middle">
|
|
<font size="7">Filesystem FAQ</font>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<table border="0" cellpadding="5" cellspacing="0" style="border-collapse: collapse"
|
|
bordercolor="#111111" bgcolor="#D7EEFF" width="100%">
|
|
<tr>
|
|
<td><a href="index.htm">Home</a>
|
|
<a href="tutorial.html">Tutorial</a>
|
|
<a href="reference.html">Reference</a>
|
|
<a href="faq.htm">FAQ</a>
|
|
<a href="release_history.html">Releases</a>
|
|
<a href="portability_guide.htm">Portability</a>
|
|
<a href="v4.html">V4</a>
|
|
<a href="v3.html">V3 Intro</a>
|
|
<a href="v3_design.html">V3 Design</a>
|
|
<a href="deprecated.html">Deprecated</a>
|
|
<a href="issue_reporting.html">Bug Reports </a>
|
|
</td>
|
|
</table>
|
|
|
|
<h1>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
readability. There was no apparent upside benefit.</p>
|
|
<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
|
|
different string and character types.</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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
free functions.</p>
|
|
<hr>
|
|
<p>© Copyright Beman Dawes, 2002</p>
|
|
<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>
|
|
</body>
|
|
</html>
|