Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

source: downloads/boost_1_34_1/libs/filesystem/doc/faq.htm @ 29

Last change on this file since 29 was 29, checked in by landauf, 17 years ago

updated boost from 1_33_1 to 1_34_1
File size: 10.3 KB
Line 
1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2<html>
3  <head>
4    <title>
5      Boost Filesystem FAQ
6    </title>
7<style type="text/css">
8 body {
9  background-color: #FFFFFF;
10 }
11 p.c1 {font-weight: bold}
12</style>
13  </head>
14  <body>
15    <h1>
16      <img border="0" src="../../../boost.png" align="middle" alt=
17      "Boost C++ libraries logo" width="277" height="86"> Filesystem
18      FAQ
19    </h1>
20
21    <p class="c1">
22      Why base the generic-path string format on POSIX?
23    </p>
24    <p>
25      <a href="design.htm#POSIX-01">[POSIX-01]</a> is an ISO Standard.
26      It is the basis for the most familiar path-string formats,
27      including the URL portion of URI's and the native Windows format.
28      It is ubiquitous and familiar.&nbsp; On many systems, it is very
29      easy to implement because it is either the native operating
30      system format (Unix and Windows) or via a operating system
31      supplied POSIX library (z/OS, OS/390, and many more.)
32    </p>
33    <p class="c1">
34      Why not use a full URI (Universal Resource Identifier) based
35      path?
36    </p>
37
38    <p>
39      <a href="design.htm#URI">URI's</a> would promise more than the
40      Filesystem Library can actually deliver, since URI's extend far
41      beyond what most operating systems consider a file or a
42      directory.&nbsp; Thus for the primary "portable script-style file
43      system operations" requirement of the Filesystem Library, full
44      URI's appear to be over-specification.
45    </p>
46    <p class="c1">
47      Why isn't <i>path</i> a base class with derived
48      <i>directory_path</i> and <i>file_path</i> classes?
49    </p>
50
51    <p>
52      Why bother?&nbsp; The behavior of all three classes is
53      essentially identical. Several early versions did require users
54      to identify each path as a file or directory path, and this
55      seemed to increase errors and decrease code readability. There
56      was no apparent upside benefit.
57    </p>
58    <p class="c1">
59      Why are fully specified paths called <i>complete</i> rather than
60      <i><a name="absolute" id="absolute">absolute</a></i>?
61    </p>
62
63    <p>
64      To avoid long-held assumptions (what do you mean, <i>"/foo"</i>
65      isn't absolute on some systems?) by programmers used to
66      single-rooted filesystems. Using an unfamiliar name for the
67      concept and related functions causes programmers to read the
68      specs rather than just assuming the meaning is known.
69    </p>
70    <p class="c1">
71      Why not support a concept of specific kinds of file systems, such
72      as posix_file_system or windows_file_system.
73    </p>
74    <p>
75      Portability is one of the most important requirements for the
76      library.&nbsp;Gaining some advantage by using features specific
77      to particular operating systems is not a requirement. There
78      doesn't appear to be much need for the ability to manipulate,
79      say, a classic Mac OS path while running on an OpenVMS machine.
80    </p>
81
82    <p>
83      Furthermore, concepts like "file system" are very slippery. What
84      happens when a NTFS or FAT file system is mounted in directory on
85      a machine running a POSIX-like operating system, for example?
86      Some of the POSIX API's may return very un-POSIX like results.
87    </p>
88    <p class="c1">
89      Why not supply a 'handle' type, and let the file and directory
90      operations traffic in it?
91    </p>
92    <p>
93      It isn't clear there is any feasible way to meet the "portable
94      script-style file system operations" requirement with such a
95      system. File systems exist where operations are usually performed
96      on some non-string handle type. The classic Mac OS has been
97      mentioned explicitly as a case where trafficking in paths isn't
98      always natural.&nbsp;&nbsp;&nbsp;
99    </p>
100
101    <p>
102      The case for the "handle" (opaque data type to identify a file)
103      style may be strongest for directory iterator value type.&nbsp;
104      (See Jesse Jones' Jan 28, 2002, Boost postings). However, as
105      class path has evolved, it seems sufficient even as the directory
106      iterator value type.
107    </p>
108    <p class="c1">
109      Why are the operations.hpp non-member functions so low-level?
110    </p>
111    <p>
112      To provide a toolkit from which higher-level functionality can be
113      created.
114    </p>
115
116    <p>
117      An extended attempt to add convenience functions on top of, or as
118      a replacement for, the low-level functionality failed because
119      there is no widely acceptable set of simple semantics for most
120      convenience functions considered.&nbsp; Attempts to provide
121      alternate semantics via either run-time options or compile-time
122      polices became overly complicated in relation to the value
123      delivered, or became contentious.&nbsp; OTOH, the specific
124      functionality needed for several trial applications was very easy
125      for the user to construct from the lower-level toolkit
126      functions.&nbsp; See <a href=
127      "design.htm#Abandoned_Designs">Failed Attempts</a>.
128    </p>
129    <p class="c1">
130      Isn't it inconsistent then to provide a few convenience
131      functions?
132    </p>
133
134    <p>
135      Yes, but experience with both this library, POSIX, and Windows
136      indicates the utility of certain convenience functions, and that
137      it is possible to provide simple, yet widely acceptable,
138      semantics for them. For example, remove_all.
139    </p>
140    <p class="c1">
141      Why are there basic_directory_iterator&lt;&gt; overloads for
142      operations.hpp predicate functions? Isn't two ways to do the same
143      thing poor design?
144    </p>
145    <p>
146      Yes, two ways to do the same thing is often a poor design
147      practice. But the iterator versions are often much more
148      efficient. Calling status() during iteration over a directory
149      containing 15,000 files took 6 seconds for the path overload, and
150      1 second for the iterator overload, for tests on a freshly booted
151      machine. Times were .90 seconds and .30 seconds, for tests after
152      prior use of the directory. This performance gain is large enough
153      to justify deviating from preferred design practices. Neither
154      overload alone meets all needs.
155    </p>
156
157    <p class="c1">
158      Why are library functions so picky about errors?
159    </p>
160    <p>
161      Safety. The default is to be safe rather than sorry. This is
162      particularly important given the reality that on many computer
163      systems files and directories are <a href="#global">globally
164      shared</a> resources, and thus subject to unexpected errors.
165    </p>
166    <p class="c1">
167      Why are errors reported by exception rather than return code or
168      error notification variable?
169    </p>
170
171    <p>
172      Safety.&nbsp;Return codes or error notification variables are
173      often ignored by programmers.&nbsp; Exceptions are much harder to
174      ignore, provided desired default behavior (program termination)
175      if not caught, yet allow error recovery if desired. Non-throwing
176      versions of functions are provided where experience indicates the
177      need.
178    </p>
179    <p class="c1">
180      Why are attributes accessed via named functions rather than
181      property maps?
182    </p>
183    <p>
184      For commonly used attributes (existence, directory or file,
185      emptiness), simple syntax and guaranteed presence outweigh other
186      considerations. Because access to many other attributes is
187      inherently system dependent, property maps are viewed as the best
188      hope for access and modification, but it is better design to
189      provide such functionality in a separate library. (Historical
190      note: even the apparently simple attribute "read-only" turned out
191      to be so system depend as to be disqualified as a "guaranteed
192      presence" operation.)
193    </p>
194
195    <p class="c1">
196      Why isn't there a set_current_directory function?
197    </p>
198    <p>
199      Global variables are considered harmful [<a href=
200      "design.htm#Wulf-Shaw-73">wulf-shaw-73</a>]. While we can't
201      prevent people from shooting themselves in the foot, we aren't
202      about to hand them a loaded gun pointed right at their big toe.
203    </p>
204    <p class="c1">
205      Why aren't <a name="wide-character_names" id=
206      "wide-character_names">wide-character names</a> supported? Why
207      not std::wstring or even a templated type?
208    </p>
209
210    <p>
211      They <u>are</u> supported, starting with version 1.33. See
212      <a href="i18n.html">Internationalization</a>.
213    </p>
214    <p class="c1">
215      Why isn't automatic name portability error detection provided?
216    </p>
217    <p>
218
219      A number (at least six) of designs for name validity error
220      detection were evaluated, including at least four complete
221      implementations.&nbsp; While the details for rejection differed,
222      all of the more powerful name validity checking designs distorted
223      other otherwise simple aspects of the library. Even the simple
224      name checking provided in prior library versions was a constant
225      source of user complaints. While name checking can be helpful, it
226      isn't important enough to justify added a lot of additional
227      complexity.
228    </p>
229    <p class="c1">
230      Why are paths sometimes manipulated by member functions and
231      sometimes by non-member functions?
232    </p>
233    <p>
234      The design rule is that purely lexical operations are supplied as
235      <i>class basic_path</i> member functions, while operations
236      performed by the operating system are provided as free functions.
237    </p>
238
239    <p class="c1">
240      Why is path <i>normalized form</i> different from <i>canonical
241      form</i>?
242    </p>
243    <p>
244      On operating systems such as POSIX which allow symbolic links to
245      directories, the normalized form of a path can represent a
246      different location than the canonical form. See <a href=
247      "design.htm#symbolic-link-use-case">use case</a> from Walter
248      Landry.
249    </p>
250
251    <hr>
252    <p>
253      Revised
254      <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
255                        06 February, 2006
256      <!--webbot bot="Timestamp" endspan i-checksum="40411" -->
257    </p>
258    <p>
259      © Copyright Beman Dawes, 2002
260    </p>
261    <p>
262
263      Use, modification, and distribution are subject to the Boost
264      Software License, Version 1.0. (See accompanying file <a href=
265      "../../../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy at
266      <a href="http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)
267    </p>
268  </body>
269</html>
Note: See TracBrowser for help on using the repository browser.