Planet

navi

home

PPS

about

screenshots

download

development

forum

Context Navigation

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

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

Rev	Line
[29]	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: