Planet

navi

home

PPS

about

screenshots

download

development

forum

Context Navigation

source: downloads/boost_1_34_1/libs/filesystem/doc/index.htm @ 45

Last change on this file since 45 was 29, checked in by landauf, 16 years ago
updated boost from 1_33_1 to 1_34_1
File size: 26.3 KB

Line
1	<html>
2
3	<head>
4	<meta http-equiv="Content-Language" content="en-us">
5	<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
6	<meta name="ProgId" content="FrontPage.Editor.Document">
7	<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
8	<title>Boost Filesystem Library</title>
9	</head>
10
11	<body bgcolor="#FFFFFF">
12
13	<h1>
14	<img border="0" src="../../../boost.png" align="center" width="277" height="86">Boost
15	Filesystem Library</h1>
16	<table border="0" cellpadding="0" width="100%">
17	<tr>
18	<td width="50%" valign="top"><font size="4">This Document</font><br>
19	<a href="#Introduction">Introduction</a><br>
20	<a href="#tutorial">Two-minute tutorial</a><br>
21	<a href="#Cautions">Cautions</a><br>
22	<a href="#Using_reference_doc">Using the Reference
23	Documentation</a><br>
24	<a href="#Examples">Examples</a><br>
25	<a href="#Implementation">Implementation</a><br>
26	<a href="#narrow-only">Restricting library to narrow
27	character paths</a><br>
28	<a href="#Building">Building the object-library</a><br>
29	<a href="#Cgywin">Notes for Cygwin users</a><br>
30	<a href="#Acknowledgements">Acknowledgements</a><br>
31	<a href="#Change-history">Change history</a></td>
32	<td width="50%" valign="top"><font size="4">Other Documents</font><br>
33	<a href="tr2_proposal.html">Reference</a><br>
34	<a href="tr2_proposal.html#TOC">Table of Contents</a><br>
35
36	<a href="tr2_proposal.html#Introduction">TR2 Introduction</a><br>
37	<a href="tr2_proposal.html#Text">Formal reference text</a><br>
38
39	<a href="tr2_proposal.html#frontmatter">Introductory
40	chapter</a><br>
41
42	<a href="tr2_proposal.html#Filesystem-library">Filesystem
43	library chapter</a><br>
44
45	<a href="tr2_proposal.html#Header-filesystem-synopsis">Header
46	<boost/filesystem.hpp> synopsis</a><br>
47	<a href="design.htm">Library Design</a><br>
48	<a href="faq.htm">FAQ</a><br>
49	<a href="portability_guide.htm">Portability Guide</a><br>
50	<a href="do-list.htm">Do-list</a><br>
51	</td>
52	</tr>
53	</table>
54	<h2><a name="Introduction">Introduction</a></h2>
55	<p>The Boost Filesystem Library provides portable facilities to query and
56	manipulate paths, files, and directories.</p>
57
58	<p>The motivation for the library is the need to perform portable script-like operations from within C++ programs. The intent is not to
59	compete with Python, Perl, or shell languages, but rather to provide portable filesystem
60	operations when C++ is already the language of choice. The <a href="design.htm">
61	design</a> encourages, but does not require, safe and portable usage.</p>
62
63	<p>Programs using the library are <b><i>portable</i></b>, both in the sense that
64	the syntax of program code is portable, and the sense that the semantics or
65	behavior of code is portable. The <a href="tr2_proposal.html#Pathname-grammar">generic path
66	grammar</a> is another important aid to portability.</p>
67
68	<p>Usage is <i><b>safe</b></i> in the sense that errors cannot be ignored since most functions throw C++
69	exceptions when errors are detected. This is also convenient for users because
70	it alleviates the need to explicitly check error
71	return codes.</p>
72
73	<p>A <a href="tr2_proposal.html">proposal</a> has been
74	submitted to the C++ Standards Committee for inclusion of the library in the
75	Standard Library Technical Report 2 (TR2). The Boost.Filesystem library will
76	stay in alignment with the TR2 Filesystem proposal as it works its way through
77	the committee process. Note, however, that namespaces and header granularity
78	differs between Boost.Filesystem and the TR2 proposal. See
79	<a href="#Using_reference_doc">Using the Reference Documentation</a>.</p>
80
81	<p>The Filesystem Library supplies several  headers:</p>
82
83	<ul>
84	<li>Header<a href="../../../boost/filesystem.hpp"> boost/filesystem.hpp</a> provides class <i>
85	basic_path, </i>a portable mechanism for representing
86	<a href="#path">paths</a> in C++ programs. Typedefs <i>path</i> and <i>
87	wpath</i> ease the most common usages of <i>basic_path</i>. Operational
88	functions provide useful query and maintenance operations on files and directories.
89	Class <i>basic_directory_iterator</i> with typdefs <i>
90	directory_iterator</i> and <i>wdirectory_iterator</i> provide iteration over
91	the contents of directories. Convenience functions and classes combine lower-level functionality
92	in useful ways.<br>
93	</li>
94	<li>Header <a href="../../../boost/filesystem/fstream.hpp">boost/filesystem<i>/</i>fstream.hpp</a> provides the same components as the C++ Standard
95	Library's <i>fstream</i> header, except
96	that files are identified by <i>basic_path</i> objects rather that <i>char *</i>'s.<br>
97	</li>
98	<li>Header <a href="../../../boost/filesystem/cerrno.hpp">
99	boost/filesystem/cerrno.hpp</a> provides POSIX errno macros used by
100	Boost.Filesystem, and two new macros (EBADHANDLE, EOTHER) not defined by
101	POSIX.</li>
102	</ul>
103	<h2>Two-minute <a name="tutorial">tutorial</a></h2>
104	<p>First some preliminaries:</p>
105	<blockquote>
106	<pre>#include "boost/filesystem.hpp" // includes all needed Boost.Filesystem declarations
107	#include <iostream> // for std::cout
108	using boost::filesystem; // for ease of tutorial presentation;
109	// a namespace alias is preferred practice in real code</pre>
110	</blockquote>
111	<p>A <a href="tr2_proposal.html#Class-template-basic_path">class <i>path</i></a> object can be created:</p>
112	<blockquote>
113	<pre>path my_path( "some_dir/file.txt" );</pre>
114	</blockquote>
115	<p>The string passed to the <i>path</i> constructor may be in a
116	<a href="tr2_proposal.html#Pathname-formats">portable generic path format</a> or an
117	implementation-defined native operating system format. Access functions
118	make <i>my_path</i> contents available to the underlying operating system API in an operating system dependent format,
119	such as <code>"some_dir:file.txt"</code>, <code>"[some_dir]file.txt"</code>,
120	<code>"some_dir/file.txt"</code>, or whatever is appropriate for the
121	operating system. If class <i>wpath</i> is used instead of class <i>path</i>,
122	translation between wide and narrow character paths is performed automatically
123	if necessary for the operating system.</p>
124	<p>Class <i>path</i> has conversion constructors from <i>const char*</i> and <i>
125	const std:: string&</i>, so that even though the Filesystem Library
126	functions used in the following code snippet have <i>const path&</i> formal
127	parameters, the user can just
128	code C-style strings as actual arguments:</p>
129	<blockquote>
130	<pre>remove_all( "foobar" );
131	create_directory( "foobar" );
132	ofstream file( "foobar/cheeze" );
133	file << "tastes good!\n";
134	file.close();
135	if ( !exists( "foobar/cheeze" ) )
136	std::cout << "Something is rotten in foobar\n";</pre>
137	</blockquote>
138	<p>To make class <i>path</i> objects easy to use in expressions, <i>operator/</i>
139	appends paths:</p>
140	<blockquote>
141	<pre>ifstream file1( arg_path / "foo/bar" );
142	ifstream file2( arg_path / "foo" / "bar" );</pre>
143	</blockquote>
144	<p>The expressions <i>arg_path / "foo/bar"</i> and <i>arg_path / "foo"
145	/ "bar"</i> yield identical results.</p>
146	<p>Paths can include references to the current directory, using "<code>.</code>"
147	notation, and the parent directory, using "<code>..</code>"
148	notation.</p>
149	<p><a href="tr2_proposal.html#Class-template-basic_directory_iterator">Class <i>basic_directory_iterator</i></a>
150	is an important component of the library. It provides an input iterator over the
151	contents of a directory, with the value type being class <i>basic_path</i>.
152	Typedefs <i>directory_iterator</i> and <i>wdirectory_iterator</i> are provided
153	to cover the most common use cases.</p>
154	<p>The following function, given a directory path and a file name, recursively
155	searches the directory and its sub-directories for the file name, returning a
156	bool, and if successful, the path to the file that was found.  The code
157	below is extracted from a real program, slightly modified for clarity:</p>
158	<blockquote>
159	<pre>bool find_file( const path & dir_path, // in this directory,
160	const std::string & file_name, // search for this name,
161	path & path_found ) // placing path here if found
162	{
163	if ( !exists( dir_path ) ) return false;
164	directory_iterator end_itr; // default construction yields past-the-end
165	for ( directory_iterator itr( dir_path );
166	itr != end_itr;
167	++itr )
168	{
169	if ( is_directory(itr->status()) )
170	{
171	if ( find_file( itr->path(), file_name, path_found ) ) return true;
172	}
173	else if ( itr->path().leaf() == file_name ) // see below
174	{
175	path_found = itr->path();
176	return true;
177	}
178	}
179	return false;
180	}</pre>
181	</blockquote>
182	<p>The expression <i>itr->path().leaf() == file_name</i>, in the line commented <i>//
183	see below</i>, calls the <i>leaf()</i> function on the <i>path</i> returned by
184	calling the <i>path()</i> function of the <i>directory_entry </i>object pointed
185	to by the iterator. <i>leaf()</i> returns a string which is a copy of the
186	last (closest to the leaf, farthest from the root) file or directory name in the
187	<i>path</i> object.</p>
188	<p>In addition to <i>leaf()</i>, several other function names use the
189	tree/root/branch/leaf metaphor.</p>
190	<p>Notice that <i>find_file()</i> does not do explicit error checking, such as
191	verifying that the <i>dir_path</i> argument really represents a directory.
192	Boost.Filesystem functions throw
193	exceptions if they do not complete successfully, so there is enough implicit
194	error checking that this application doesn't need to supply additional error
195	checking code unless desired. Several Boost.Filesystem functions have non-throwing
196	versions, to ease use cases where exceptions would not be appropriate.</p>
197	<blockquote>
198	<p><i>Note: </i>Recursive
199	directory iteration was added as a convenience function after the above tutorial code
200	was written, so nowadays you
201	don't have to actually code the recursion yourself.</p>
202	</blockquote>
203	<h2><a name="Cautions">Cautions</a></h2>
204	<p>After reading the tutorial you can dive right into simple,
205	script-like programs using the Filesystem Library! Before doing any serious
206	work, however, there a few cautions to be aware of:</p>
207	<h4><b>Effects and Postconditions not guaranteed in the presence of race-conditions</b></h4>
208	<p>Filesystem function specifications follow the C++ Standard Library form, specifying behavior in terms of
209	effects and postconditions. If
210	a <a href="tr2_proposal.html#Race-condition">race-condition</a> exists, a function's
211	postconditions may no longer be true by the time the function returns to the
212	caller.</p>
213	<blockquote>
214	<p><b><i>Explanation: </i></b>The state of files and directories is often
215	globally shared, and thus may be changed unexpectedly by other threads,
216	processes, or even other computers having network access to the filesystem. As an
217	example of the difficulties this can cause, note that the following asserts
218	may fail:</p>
219	<blockquote>
220	<p><code>assert( exists( "foo" ) == exists( "foo" ) );  //
221	(1)<br>
222	<br>
223	remove_all( "foo" );<br>
224	assert( !exists( "foo" ) );  // (2)<br>
225	<br>
226	assert( is_directory( "foo" ) == is_directory( "foo" ) ); //
227	(3)</code></p>
228	</blockquote>
229	<p>(1) will fail if a non-existent "foo" comes into existence, or an
230	existent "foo" is removed, between the first and second call to <i>exists()</i>.
231	This could happen if, during the execution of the example code, another thread,
232	process, or computer is also performing operations in the same directory.</p>
233	<p>(2) will fail if between the call to <i>remove_all()</i> and the call to
234	<i>exists()</i> a new file or directory named "foo" is created by another
235	thread, process, or computer.</p>
236	<p>(3) will fail if another thread, process, or computer removes an
237	existing file "foo" and then creates a directory named "foo", between the
238	example code's two calls to <i>is_directory()</i>.</p>
239	</blockquote>
240	<h4><b>May throw exceptions</b></h4>
241	<p>Unless otherwise specified, Boost.Filesystem functions throw <i>
242	<a href="tr2_proposal.html#basic_filesystem_error-constructors">basic_filesystem_error</a></i>
243	exceptions if they cannot successfully complete their operational
244	specifications. Also, implementations may use C++ Standard Library functions,
245	which may throw <i>std::bad_alloc</i>. These exceptions may be thrown even
246	though the error condition leading to the exception is not explicitly specified
247	in the function's "Throws" paragraph.</p>
248	<p>All exceptions thrown by the Filesystem
249	Library are implemented by calling <a href="../../utility/throw_exception.html">
250	boost::throw_exception()</a>. Thus exact behavior may differ depending on
251	BOOST_NO_EXCEPTIONS at the time the filesystem source files are compiled.</p>
252	<p>Non-throwing versions are provided of several functions that are often used
253	in contexts where error codes may be the preferred way to report an error.</p>
254	<h2><a name="Using_reference_doc">Using the Reference Documentation</a></h2>
255	<p>The proposal for adding Boost.Filesystem to the C++ Standard Library's
256	Technical Report 2 is used as the <a href="tr2_proposal.html">Reference
257	Documentation</a>. This eliminates the need to maintain two sets of
258	documentation, but means that the actual Boost.Filesystem library differs from
259	this reference documentation in several ways.</p>
260	<ul>
261	<li>The Boost.Filesystem header is <a href="../../../boost/filesystem.hpp">
262	<code><boost/filesystem.hpp></code></a> rather than <code><filesystem></code>.</li>
263	<li>The namespace is <code>boost::filesystem</code> rather than <code>
264	std::tr2::sys</code>.</li>
265	<li>Several legacy interfaces are provided by Boost.Filesystem that are not
266	part of the TR2 proposal.</li>
267	</ul>
268	<h2><a name="Examples">Examples</a></h2>
269	<h3>simple_ls.cpp</h3>
270	<p>The example program <a href="../example/simple_ls.cpp">simple_ls.cpp</a> is
271	given a path as a command line argument. Since the command line argument may be
272	a relative path, the complete path is determined so that messages displayed
273	can be more precise.</p>
274	<p>The program checks to see if the path exists; if not a message is printed.</p>
275	<p>If the path identifies a directory, the directory is iterated through,
276	printing the name of the entries found, and an indication if they are
277	directories. A count of directories and files is updated, and then printed after
278	the iteration is complete.</p>
279	<p>If the path is for a file, a message indicating that is printed.</p>
280	<p>Try compiling and executing <a href="../example/simple_ls.cpp">simple_ls.cpp</a>
281	to see how it works on your system. Try various path arguments to see what
282	happens.</p>
283	<h3>Other examples</h3>
284	<p>The programs used to generate the Boost regression test status tables use the
285	Filesystem Library extensively.  See:</p>
286	<ul>
287	<li><a href="../../../tools/regression/process_jam_log.cpp">
288	process_jam_log.cpp</a></li>
289	<li><a href="../../../tools/regression/compiler_status.cpp">
290	compiler_status.cpp</a></li>
291	</ul>
292	<p>Test programs are sometimes useful in understanding a library, as they
293	illustrate what the developer expected to work and not work. See:</p>
294	<ul>
295	<li><a href="../test/wide_test.cpp">wide_test.cpp</a></li>
296	<li><a href="../test/path_test.cpp">path_test.cpp</a></li>
297	<li><a href="../test/operations_test.cpp">operations_test.cpp</a></li>
298	<li><a href="../test/fstream_test.cpp">fstream_test.cpp</a></li>
299	</ul>
300	<h2><a name="Implementation">Implementation</a></h2>
301	<p>The current implementation supports operating systems which provide
302	either the POSIX or Windows API.</p>
303	<p>The library is in regular use on Apple OS X, HP-UX, IBM AIX, Linux,
304	Microsoft Windows, SGI IRIX, and Sun Solaris operating systems using a variety
305	of compilers.</p>
306	<h2><a name="narrow-only">Restricting library to narrow character paths</a></h2>
307	<p>Compilers or standard libraries which do not support wide characters (wchar_t)
308	or wide character strings (std::wstring) are detected automatically, and cause
309	the library to compile code that is restricted to narrow character paths
310	(boost::filesystem::path). Users can force this restriction by defining the
311	macro BOOST_FILESYSTEM_NARROW_ONLY. That may be useful for dealing with legacy
312	compilers or operating systems.</p>
313	<h2><a name="Building">Building</a> the object-library</h2>
314	<p>The object-library will normally be built automatically. See
315	<a href="../../../more/getting_started.html">Getting Started</a>. It can also be
316	built manually using a <a href="../build/Jamfile.v2">Jamfile</a>
317	supplied in directory libs/filesystem/build, or the user can construct an IDE
318	project or make file which includes the object-library source files.</p>
319	<p>The object-library source files are
320	supplied in directory <a href="../src">libs/filesystem/src</a>. These source files implement the
321	library for POSIX or Windows compatible operating systems; no implementation is
322	supplied for other operating systems. Note that many operating systems not
323	normally thought of as POSIX systems, such as mainframe legacy
324	operating systems or embedded operating systems, support POSIX compatible file
325	systems which will work with the Filesystem Library.</p>
326	<p>The object-library can be built for static or dynamic (shared/dll) linking.
327	This is controlled by the BOOST_ALL_DYN_LINK or BOOST_FILESYSTEM_DYN_LINK
328	macros. See the <a href="../../../more/separate_compilation.html">Separate
329	Compilation</a> page for a description of the techniques used.</p>
330	<h3>Note for <a name="Cgywin">Cygwin</a> users</h3>
331	<p>The library's implementation code automatically detects the current platform,
332	and compiles the POSIX or Windows implementation code accordingly. Automatic
333	platform detection during object library compilation can be overridden by
334	defining either BOOST_POSIX_API or BOOST_WINDOWS_API macros. With the exception of the Cygwin
335	environment, there is usually no reason to define these macros, as the
336	software development kits supplied with most compilers only support a single
337	platform.</p>
338	<p>The <a href="http://www.cygwin.com/">Cygwin</a> package of tools supports
339	traditional Windows usage, but also provides an emulation layer and other tools
340	which can be used to make Windows act as Linux (and thus POSIX), and provide the
341	Linux look-and-feel. GCC is usually the compiler of choice in this environment,
342	as it can be installed via the Cygwin install process. Other compilers can also
343	use the Cygwin emulation of POSIX, at least in theory.</p>
344	<p>Those wishing to use the Cygwin POSIX emulation layer should define the
345	BOOST_POSIX_API macro when compiling bother user programs and the
346	Boost.Filesystem's object-library.</p>
347	<h2><a name="Acknowledgements">Acknowledgements</a></h2>
348	<p>The Filesystem Library was designed and implemented by Beman Dawes. The
349	original <i>directory_iterator</i> and <i>filesystem_error</i> classes were
350	based on prior work from Dietmar Kühl, as modified by Jan Langer. Thomas Witt
351	was a particular help in later stages of initial development. Peter Dimov and
352	Rob Stewart made many useful suggestions and comments over a long period of
353	time. Howard Hinnant helped with internationalization issues.</p>
354
355	<p>Key <a href="design.htm#Requirements">design requirements</a> and
356	<a href="design.htm#Realities">design realities</a> were developed during
357	extensive discussions on the Boost mailing list, followed by comments on the
358	initial implementation. Numerous helpful comments were then received during the
359	Formal Review.<p>Participants included
360	Aaron Brashears,
361	Alan Bellingham,
362	Aleksey Gurtovoy,
363	Alex Rosenberg,
364	Alisdair Meredith,
365	Andy Glew,
366	Anthony Williams,
367	Baptiste Lepilleur,
368	Beman Dawes,
369	Bill Kempf,
370	Bill Seymour,
371	Carl Daniel,
372	Chris Little,
373	Chuck Allison,
374	Craig Henderson,
375	Dan Nuffer,
376	Dan'l Miller,
377	Daniel Frey,
378	Darin Adler,
379	David Abrahams,
380	David Held,
381	Davlet Panech,
382	Dietmar Kuehl,
383	Douglas Gregor,
384	Dylan Nicholson,
385	Ed Brey,
386	Eric Jensen,
387	Eric Woodruff,
388	Fedder Skovgaard,
389	Gary Powell,
390	Gennaro Prota,
391	Geoff Leyland,
392	George Heintzelman,
393	Giovanni Bajo,
394	Glen Knowles,
395	Hillel Sims,
396	Howard Hinnant,
397	Jaap Suter,
398	James Dennett,
399	Jan Langer,
400	Jani Kajala,
401	Jason Stewart,
402	Jeff Garland,
403	Jens Maurer,
404	Jesse Jones,
405	Jim Hyslop,
406	Joel de Guzman,
407	Joel Young,
408	John Levon,
409	John Maddock,
410	John Williston,
411	Jonathan Caves,
412	Jonathan Biggar,
413	Jurko,
414	Justus Schwartz,
415	Keith Burton,
416	Ken Hagen,
417	Kostya Altukhov,
418	Mark Rodgers,
419	Martin Schuerch,
420	Matt Austern,
421	Matthias Troyer,
422	Mattias Flodin,
423	Michiel Salters,
424	Mickael Pointier,
425	Misha Bergal,
426	Neal Becker,
427	Noel Yap,
428	Parksie,
429	Patrick Hartling, Pavel Vozenilek,
430	Pete Becker,
431	Peter Dimov,
432	Rainer Deyke,
433	Rene Rivera,
434	Rob Lievaart,
435	Rob Stewart,
436	Ron Garcia,
437	Ross Smith,
438	Sashan,
439	Steve Robbins,
440	Thomas Witt,
441	Tom Harris,
442	Toon Knapen,
443	Victor Wagner,
444	Vincent Finn,
445	Vladimir Prus, and
446	Yitzhak Sapir
447
448	<p>A lengthy discussion on the C++ committee's library reflector illuminated the "illusion
449	of portability" problem, particularly in postings by PJ Plauger and Pete Becker.</p>
450
451	<p>Walter Landry provided much help illuminating symbolic link use cases for
452	version 1.31.0.</p>
453
454	<h3>Version 1.34 (<a href="i18n.html">i18n</a>) acknowledgements</h3>
455
456	<p>So many people have contributed comments and bug reports that it isn't any
457	longer possible to acknowledge them individually. That said, Peter Dimov and Rob
458	Stewart need to be specially thanked for their many constructive criticisms and
459	suggestions. Terence
460	Wilson and Chris Frey contributed timing programs which helped illuminate
461	performance issues.</p>
462
463	<h2><a name="Change-history">Change history</a></h2>
464
465	<h3><a href="i18n.html">Version 1.34.0</a></h3>
466
467	<ul>
468	<li><a href="i18n.html#Internationalization">Internationalization</a>, provided by
469	class templates <i>basic_path</i>, <i>basic_filesystem_error</i>, and <i>
470	basic_directory_iterator</i>.</li>
471	<li><a href="i18n.html#Simplification">Simplification</a> of the path interface,
472	including elimination of distinction between native and generic formats,
473	and separation of name checking functionality from general path functionality.</li>
474	<li><a href="i18n.html#Rationalization">Rationalization</a> of predicate
475	function design, including the addition of several new functions.</li>
476	<li><a href="i18n.html#Preservation">Preservation</a> of existing user code whenever
477	possible. Deprecated features (<i>symbolic_link_exists()</i>, etc.) remain
478	available for legacy code.</li>
479	<li>Clearer specification, by reference to [<a href="design.htm#POSIX-01">POSIX-01</a>],
480	the ISO/IEEE Single Unix Standard, with provisions for Windows and other
481	operating systems.</li>
482	<li>New functions <a href="tr2_proposal.html#Status-functions">status</a>,
483	<a href="tr2_proposal.html#Status-functions">symlink_status</a>,
484	<a href="tr2_proposal.html#Predicate-functions">is_file</a>,
485	<a href="tr2_proposal.html#Predicate-functions">is_symlink</a>,
486	<a href="tr2_proposal.html#Operations-functions">create_hard_link</a>,
487	<a href="tr2_proposal.html#Operations-functions">create_symlink</a>, path member and non-member swap, path inserter, path
488	extractor, additional path relational and "/" operator overloads, additional
489	path member template functions taking iterator arguments.</li>
490	<li><a href="i18n.html#More_efficient">More efficient operations</a> when iterating over directories.</li>
491	<li>Separation within the implementation of the distinction between the native
492	operating system path syntax and API. This is important for CYGWIN users
493	because it allows them to build for either the Windows or POSIX API's.</li>
494	<li>Numerous small implementation fixes.</li>
495	</ul>
496
497	<h3>Version 1.33.0</h3>
498
499	<ul>
500	<li>Some small implementation fixes.</li>
501	</ul>
502
503	<h3>Version 1.32.0</h3>
504
505	<ul>
506	<li><a href="tr2_proposal.html#Attribute-functions">file_size()</a> function added.</li>
507	<li>Class path <a href="tr2_proposal.html#basic_path-non-member-functions">relational operators</a> added.</li>
508	<li><a href="tr2_proposal.html#Predicate-functions">equivalent()</a> function added.</li>
509	<li><a href="tr2_proposal.html#Operations-functions">create_directory()</a> no longer
510	throws if the directory already exists. A bool is returned, indicating that
511	the directory did not preexist. Similar changes made to
512	<a href="tr2_proposal.html#Convenience-functions">create_directories()</a>.</li>
513	<li><a href="#Cgywin">Docs added</a> for users wishing Cygwin/POSIX behavior
514	on Windows.</li>
515	<li>For POSIX, Large File Support (LSF) is enabled if available, such as on
516	Linux.</li>
517	<li><a href="tr2_proposal.html#initial_path">current_path()</a> and
518	<a href="tr2_proposal.html#initial_path">initial_path()</a> on POSIX now handle
519	very long paths correctly.</li>
520	</ul>
521
522	<h3>Version 1.31.0</h3>
523
524	<ul>
525	<li>The object library can now be <a href="#Building">built</a> for either
526	static or dynamic (shared/dll) linking. </li>
527	<li>Several added functions, including improved checking for directory and
528	file name portability. See <a href="portability_guide.htm#name_check_functions">
529	Name check functions</a>.</li>
530	<li>Separation of canonical form and normalized form and a new path member
531	function normalize(). This changes behavior,
532	in that canonical form is now different, but eliminates a subtle
533	<a href="design.htm#symbolic-link-use-case">bug</a> when symbolic links to
534	directories are present. </li>
535	</ul>
536
537	<hr>
538	<p>Revised
539	<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->03 June, 2007<!--webbot bot="Timestamp" endspan i-checksum="19946" --></p>
540
541	<p>© Copyright Beman Dawes, 2002-2005</p>
542	<p> Use, modification, and distribution are subject to the Boost Software
543	License, Version 1.0. (See accompanying file <a href="../../../LICENSE_1_0.txt">
544	LICENSE_1_0.txt</a> or copy at <a href="http://www.boost.org/LICENSE_1_0.txt">
545	www.boost.org/LICENSE_1_0.txt</a>)</p>
546
547	</body>
548
549	</html>

Note: See TracBrowser for help on using the repository browser.

Download in other formats: