Subject: [Boost-commit] svn:boost r77357 - in trunk: boost/filesystem/v3 libs/filesystem/v3/doc libs/filesystem/v3/doc/src libs/filesystem/v3/src libs/filesystem/v3/test
From: bdawes_at_[hidden]
Date: 2012-03-17 08:53:26
Author: bemandawes
Date: 2012-03-17 08:53:25 EDT (Sat, 17 Mar 2012)
New Revision: 77357
URL: http://svn.boost.org/trac/boost/changeset/77357
Log:
Add class path preferred_separator
Text files modified:
trunk/boost/filesystem/v3/path.hpp | 28 +++---
trunk/libs/filesystem/v3/doc/reference.html | 17 ++--
trunk/libs/filesystem/v3/doc/release_history.html | 7 +
trunk/libs/filesystem/v3/doc/src/source.html | 9 +-
trunk/libs/filesystem/v3/doc/src/tr2_snippets.html | 154 +++++++++++++++++++++++++++------------
trunk/libs/filesystem/v3/src/path.cpp | 12 +--
trunk/libs/filesystem/v3/test/path_unit_test.cpp | 4
7 files changed, 145 insertions(+), 86 deletions(-)
Modified: trunk/boost/filesystem/v3/path.hpp
==============================================================================
--- trunk/boost/filesystem/v3/path.hpp (original)
+++ trunk/boost/filesystem/v3/path.hpp 2012-03-17 08:53:25 EDT (Sat, 17 Mar 2012)
@@ -58,13 +58,16 @@
// value_type is the character type used by the operating system API to
// represent paths.
-# ifdef BOOST_WINDOWS_API
- typedef wchar_t value_type;
-# else
- typedef char value_type;
-# endif
- typedef std::basic_string<value_type> string_type;
- typedef std::codecvt<wchar_t, char, std::mbstate_t> codecvt_type;
+# ifdef BOOST_WINDOWS_API
+ typedef wchar_t value_type;
+ BOOST_STATIC_CONSTEXPR value_type preferred_separator = L'\\';
+# else
+ typedef char value_type;
+ BOOST_STATIC_CONSTEXPR value_type preferred_separator = '/';
+# endif
+ typedef std::basic_string<value_type> string_type;
+ typedef std::codecvt<wchar_t, char,
+ std::mbstate_t> codecvt_type;
// ----- character encoding conversions -----
@@ -406,15 +409,10 @@
iterator begin() const;
iterator end() const;
- // ----- static members -----
-
- // ----- imbue -----
-
- static std::locale imbue(const std::locale& loc);
-
- // ----- codecvt -----
+ // ----- static member functions -----
- static const codecvt_type& codecvt()
+ static std::locale imbue(const std::locale& loc);
+ static const codecvt_type& codecvt()
{
return *wchar_t_codecvt_facet();
}
Modified: trunk/libs/filesystem/v3/doc/reference.html
==============================================================================
--- trunk/libs/filesystem/v3/doc/reference.html (original)
+++ trunk/libs/filesystem/v3/doc/reference.html 2012-03-17 08:53:25 EDT (Sat, 17 Mar 2012)
@@ -20,17 +20,17 @@
*/
body {
- font-family: sans-serif;
- margin: 1em;
- max-width : 8.5in;
- }
+ font-family: sans-serif;
+ margin: 1em;
+ max-width : 8.5in;
+ }
-table { margin: 0.5em; }
+table { margin: 0.5em; }
-pre { background-color:#D7EEFF }
+pre { background-color:#D7EEFF }
-ins { background-color:#A0FFA0 }
-del { background-color:#FFA0A0 }
+ins { background-color:#A0FFA0 }
+del { background-color:#FFA0A0 }
/*** end ***/
</style>
@@ -632,6 +632,7 @@
typedef <b><i>see below</i></b> value_type; // char for POSIX, wchar_t for Windows
typedef std::basic_string<value_type> string_type;
typedef std::codecvt<wchar_t, char, std::mbstate_t> codecvt_type;
+ constexpr value_type preferred_separator;
// constructors and destructor
path();
Modified: trunk/libs/filesystem/v3/doc/release_history.html
==============================================================================
--- trunk/libs/filesystem/v3/doc/release_history.html (original)
+++ trunk/libs/filesystem/v3/doc/release_history.html 2012-03-17 08:53:25 EDT (Sat, 17 Mar 2012)
@@ -36,6 +36,11 @@
</tr>
</table>
+<h2>1.50.0</h2>
+<ul>
+ <li>Add constexpr value_type preferred_separator to class path.</li>
+</ul>
+
<h2>1.49.0</h2>
<ul>
<li>Fix #3714,
@@ -118,7 +123,7 @@
</ul>
<hr>
<p>Revised
-<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->24 January, 2012<!--webbot bot="Timestamp" endspan i-checksum="38510" --></p>
+<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->17 March, 2012<!--webbot bot="Timestamp" endspan i-checksum="28827" --></p>
<p>© Copyright Beman Dawes, 2011</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">
Modified: trunk/libs/filesystem/v3/doc/src/source.html
==============================================================================
--- trunk/libs/filesystem/v3/doc/src/source.html (original)
+++ trunk/libs/filesystem/v3/doc/src/source.html 2012-03-17 08:53:25 EDT (Sat, 17 Mar 2012)
@@ -23,12 +23,12 @@
Filesystem TR2 Proposal
$def WHAT "Clause"
$def SNIPPET_FILE "tr2_snippets.html"
- $def HEADER "files"
+ $def HEADER "filesystem"
$def NAMESPACE std
- $def SUBNAMESPACE files
- $def NAMESPACE_BEGIN "namespace std { namespace tr2 { namespace files {
+ $def SUBNAMESPACE filesystem
+ $def NAMESPACE_BEGIN "namespace std { namespace tbd { namespace filesystem {
"
- $def NAMESPACE_END "} } } // namespaces std::tr2::files"
+ $def NAMESPACE_END "} } } // namespaces std::tbd::filesystem"
$endif
</title>
<style type="text/css">
@@ -588,6 +588,7 @@
typedef <b><i>see below</i></b> value_type; // char for POSIX, wchar_t for Windows
typedef std::basic_string<value_type> string_type;
typedef std::codecvt<wchar_t, char, std::mbstate_t> codecvt_type;
+ constexpr value_type preferred_separator;
// constructors and destructor
path();
Modified: trunk/libs/filesystem/v3/doc/src/tr2_snippets.html
==============================================================================
--- trunk/libs/filesystem/v3/doc/src/tr2_snippets.html (original)
+++ trunk/libs/filesystem/v3/doc/src/tr2_snippets.html 2012-03-17 08:53:25 EDT (Sat, 17 Mar 2012)
@@ -18,7 +18,7 @@
<tr>
<td width="153" align="left" valign="top">Date:</td>
<td width="426">
- <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y-%m-%d" startspan -->2012-02-02<!--webbot bot="Timestamp" endspan i-checksum="12106" --></td>
+ <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y-%m-%d" startspan -->2012-03-16<!--webbot bot="Timestamp" endspan i-checksum="12179" --></td>
</tr>
<tr>
<td width="153" align="left" valign="top">Project:</td>
@@ -31,28 +31,37 @@
</table>
-<h1>Filesystem Library for C++11/TR2 (Revision 2)</h1>
+<h1><span style="background-color: #FFFF00">Draft</span><br>
+Filesystem Library Proposal (Revision 3)</h1>
-<p>This paper proposes that the filesystem library component of <i>C++ Standard
-Library Technical Report 2</i> be based on Version 3 of the Boost Filesystem
+<p>This paper proposes a filesystem library component suitable for a <i>C++
+Standard Library Technical Report</i> or for the <i>C++ Standard Library</i>.
+The proposed library is based on Version 3 of the Boost Filesystem
Library (see <a href="http://www.boost.org/libs/filesystem">
www.boost.org/libs/filesystem</a>). Preliminary wording is provided. A
<a href="#TODO">TODO</a> list identifies remaining work to be done.</p>
-<h2>Revision history </h2>
+<h2>Revision history</h2>
-<p><span style="background-color: #FFFF00">N????=12-????</span>, Filesystem Library for C++11/TR2 (Revision
+<p><span style="background-color: #FFFF00">D????=12-????</span></p>
+
+
+<p>N3365=12-0055, Filesystem Library Proposal (Revision
2). Changes
include:</p>
<ul>
+ <li>Namespaces changed to <code>std::tbd::filesystem</code> per
+ <a href="#Issues-List">issue
+ 1</a> discussion in Kona.</li>
<li>Removed references to Boost within the proposed wording.</li>
- <li>Corrected namespaces and made other minor fixes to the proposed wording.</li>
+ <li>Minor fixes to the proposed wording.</li>
<li>Added Issue 7: How should class path inserter and extractor be specified?</li>
+ <li>Marked up all issues to reflect Kona LWG discussions.</li>
</ul>
@@ -142,9 +151,6 @@
application is correct.</li>
<li>Boost.Filesystem needs to implement <code>char16_t</code> and <code>char32_t</code> support to verify the
specification for these is correct.</li>
- <li>Replace path inserter and extractor <i>Effects</i> with prose, since the
- current wording relies on
- <code>boost::io::quoted</code></span>.</li>
<li>The Boost implementation has more class path non-member relational
functions that shown in the docs, and the specific set of relational
functions varies between Windows and POSIX. Figure out what's happening and
@@ -153,8 +159,40 @@
implemented. Expose <code>path_traits</code>?</li>
<li><i>Effects</i> for <code>copy</code> and <code>copy_directory</code>
need to be reviewed, revised, tested, peer reviewed.</li>
- <li>Review changes to header <fstream>. Add semantics. Add section
- names. Verify still in sync with WP.</li>
+ <li>Dinkumware/Microsoft report slightly different results for Decomposition
+ table. Rerun table. Check discrepancies.</li>
+ <li>Apply issue resolutions from Kona.</li>
+ <li>Remove registered trademarks from normative text per ISO policy.</li>
+ <li>Review Nick Stoughton's email for suggestions, action items.</li>
+ <li>Change <code>time_t</code> to <code>chrono system_clock::time_point</code>,
+ per LWG discussion in Kona. </li>
+ <li>Add [section.name] and, if possible, section numbering, per LWG
+ discussion in Kona.</li>
+ <li>Add Ed Smith-Rowland's suggestion: <br>
+ >path& path+=(const path& p);<br>
+ > and<br>
+ > path operator+(const path& lhs, const path& rhs);<br>
+ > to tack on things like suffixes or numbers on the end of files.<br>
+ > This has no real semantics, it just concatenates pathnames.</li>
+ <li>Ed Smith-Rowland:<br>
+ > I found it less confusing to switch to positive logic for
+ recursive_directory_iterator:<br>
+ > bool no_push_pending() const noexcept;<br>
+ > to say<br>
+ > bool is_push_pending() const noexcept;<br>
+ ><br>
+ > and<br>
+ > void no_push(bool value=true);<br>
+ > to say<br>
+ > void push_pending(bool value=false);<br>
+ > or<br>
+ > void set_push_pending(bool value=false);<br>
+ > I found it less confusing and I think other parts of the library strive
+ for this.</li>
+ <li>recursive_directory_iterator is specified in terms of private data
+ members. Remove these (including the comment!) and specify in terms of
+ behavior only.<br>
+ </li>
</ul>
$endid
@@ -239,9 +277,10 @@
<hr>
<h2><a name="Issues-List">Issues List</a></h2>
<hr>
-<h3>Issue 1: What is the appropriate namespace?</h3>
+<h3>Issue 1: What is the appropriate namespace? Status:
+Tentatively resolved</h3>
<h4>Discussion</h4>
-<p>The proposal places the library in <code>namespace std::tr2::$SUBNAMESPACE;</code>.
+<p>The N3335 proposal places the library in namespace <code>std::tr2::files</code>.
Rationale for a sub-namespace is that the library uses several names that don't
seem appropriate for namespace <code>tr2</code> since full standardization would
then put the names into <code>std</code>. The function names <code>remove</code>
@@ -249,12 +288,17 @@
in behavior from current standard library functions with those names. It also
doesn't seem desirable to preempt names like <code>equivalent</code> and <code>
status</code>.</p>
-<p>The Boost Filesystem library used <code>namespace boost::filesystem</code>,
-but that always seemed a bit too long.</p>
-<h4>Proposed resolution</h4>
-<p>Status quo. Leave in <code>namespace std::tr2::$SUBNAMESPACE;</code>.</p>
+<h4>Resolution</h4>
+<p><i>Kona: Strong support for <code>filesystem</code> as the library's
+namespace. Strong support for a technical report namespace that alerts uses that
+contents are likely to change if and when they later get moved into the
+standard. </i></p>
+<p><i>No decision yet on a TR namespace; <code>experimental</code> being used as
+a placeholder. Thus the full namespace is changed to <code>
+std::experimental::filesystem.</code></i></p>
<hr>
-<h3>Issue 2: Excessive use of <code>const codecvt_type&</code> arguments</h3>
+<h3>Issue 2: Excessive use of <code>const codecvt_type&</code> arguments
+Status: Open</h3>
<h4>Discussion</h4>
<p>Users sometimes need to do path conversions that use something other than the
imbued codecvt facet. The need is particularly acute in multi-threaded
@@ -263,38 +307,45 @@
function where the need might possibly arise is excessive because its use is so
rare and it adds considerable interface clutter.</p>
<h4>Proposed resolution</h4>
-<p dir="ltr">Remove all existing class path <code>const codecvt_type&</code>
-arguments.</p>
-<p>Add an additional non-member function:</p>
-<blockquote>
- <pre>unspecified-iterator-type convert(<code>const path& p, const codecvt_type& codecvt</code>);</pre>
- <p dir="ltr"><i>Returns: </i>An unspecified iterator type whose value type is
- <code>path::value_type</code>. The returned iterator points to the beginning
- of a sequence equivalent to <code>p.native()</code> with encoding as specified
- by <code>codecvt</code>.</p>
-</blockquote>
+<p dir="ltr"><i>Kona:</i></p>
+<p dir="ltr"><i>Remove all existing class path <code>const codecvt_type&</code>
+arguments.</i></p>
+<p dir="ltr"><i>Beman to pursue separate encoding conversion functionality, per
+Thursday N3336 "Adapting standard library strings and IO to a Unicode World"
+discussion. See Kona wiki.</i></p>
+<p dir="ltr"><i>If a separate encoding conversion facility isn't possible, then
+some form of minimal class path encoding conversion facility will be needed.
+But..., the LWG would like to see use cases and clearer explanation of
+motivation before deciding on specifics, and be very sure that there is no way
+to achieve with existing std library functionality, albeit with some loss of
+efficiency.</i></p>
<hr>
-<h3>Issue 3: Possible "implicit cast to native type"?</h3>
+<h3>Issue 3: Possible "implicit cast to native type"?
+Status: Open</h3>
<h4>Discussion</h4>
<p>In Bloomington there was discussion of "implicit cast to implicit cast to
native OS type to inter operate with existing iostream library and native
functions instead of modifying fstream".</p>
-<p>Beman comments: I wasn't in Bloomington and am not sure of the context of the
-above. N3239 inadvertently included the Boost docs for <fstream> rather than
-suggested <fstream> changes for TR2, and that may have caused some confusion. Or
-maybe I'm just missing something from the wiki notes. Some further discussions
-are needed to better define the issue.</p>
<h4>Proposed resolution</h4>
+<p><i>Kona: The Dinkumware/Microsoft implementation has added an implicit
+conversion to the string type, eliminating any need to modify fstream.
+(Discussion: might be safer to make the implicit conversion protected, then make
+fstream classes friends).</i></p>
+<p><i>Action: Beman to investigate, test, as avoiding modification of existing
+header and classes is much desired.</i></p>
<hr>
-<h3>Issue 4: Given move semantics, it is best not to return const strings.</h3>
+<h3>Issue 4: Given move semantics, it is best not to return const strings.
+Status: Resolved</h3>
<h4>Discussion</h4>
<p>The issue title pretty much says it all.</p>
<h4>Proposed resolution</h4>
-<p>As part of the C++11 refinements to the interface, review returns of const
-strings and change to plain strings where appropriate.</p>
+<p><i>Kona: Return plain strings. Remove the permission for implementations to
+return const refs, since uses are not in performace critical code and subtle
+portability bugs may occur.</i></p>
+<p><i>Action: Beman to apply to proposed wording.</i></p>
<hr>
<h3>Issue 5: Is there a way to handle characters that are illegal for particular
-OS?</h3>
+OS? Status: NAD</h3>
<h4>Discussion</h4>
<p>Question raised by Pablo in Bloomington.</p>
<h4>Proposed resolution</h4>
@@ -304,15 +355,20 @@
believe it should be deferred to some future release since (1) it is complex
enough that I'd like to see actual implementation and use experience (presumably
via Boost), and (2) I can't recall a user ever requesting such a feature.</p>
+<p><i>Kona: No consensus for change, since there doesn't appear to be any
+compelling use case.</i></p>
<hr>
-<h3>Issue 6: Could allocator support be added to class path?</h3>
+<h3>Issue 6: Could allocator support be added to class path?
+Status: Open</h3>
<h4>Discussion</h4>
<p>Question raised by a committee member in private email.</p>
-<p>Comment from Beman: How would allocator support work, given that class path
-is not a template?</p>
-<h4>Proposed resolution</h4>
+<p><i>Kona: Much discussion.</i></p>
+<p><i>Action: Alisdair to write paper, based on a real implementation, so that
+it is possible to assess the impact on interface, performance, etc.</i></p>
+<p><i>Post-Kona: Alisdair will defer paper until after TR. </i></p>
<hr>
-<h3>Issue 7: How should class path inserter and extractor be specified?</h3>
+<h3>Issue 7: How should class path inserter and extractor be specified?
+Status: Resolved</h3>
<h4>Discussion</h4>
<p>Class <code>path</code> currently is specified to used the Boost detail <code>
quoted</code> stream manipulator. A path object is inserted delimited by quotes,
@@ -326,11 +382,11 @@
have to change the specification. Since the <code>quoted</code> stream
manipulator is a handy little component, the issue is raised as to whether it
should go in TR2.</p>
-<h4>Proposed resolution</h4>
-<p><b>Option 1:</b> Add Boost's <code>quoted</code> stream manipulator to TR2,
-and change the Filesystem docs to reference it.</p>
-<p><b>Option 2:</b> Specify the path inserter and extractor to have the desired
-behavior with reference to how it is achieved. </p>
+<h4>Resolution</h4>
+<p><i>Kona: Specify the path inserter and extractor to have the desired
+behavior without reference to how it is achieved. (If someone wants to propose a
+quoted manipulator, that's a separate proposal for a different TR.)</i></p>
+<p><i>Action: Beman to apply to proposed wording.</i></p>
<hr>
<p>$endid
Modified: trunk/libs/filesystem/v3/src/path.cpp
==============================================================================
--- trunk/libs/filesystem/v3/src/path.cpp (original)
+++ trunk/libs/filesystem/v3/src/path.cpp 2012-03-17 08:53:25 EDT (Sat, 17 Mar 2012)
@@ -78,7 +78,6 @@
# ifdef BOOST_WINDOWS_API
const wchar_t separator = L'/';
- const wchar_t preferred_separator = L'\\';
const wchar_t* const separators = L"/\\";
const wchar_t* separator_string = L"/";
const wchar_t* preferred_separator_string = L"\\";
@@ -91,7 +90,6 @@
# else
const char separator = '/';
- const char preferred_separator = '/';
const char* const separators = "/";
const char* separator_string = "/";
const char* preferred_separator_string = "/";
@@ -106,7 +104,7 @@
{
return c == separator
# ifdef BOOST_WINDOWS_API
- || c == preferred_separator
+ || c == path::preferred_separator
# endif
;
}
@@ -144,7 +142,6 @@
{
namespace filesystem3
{
-
path& path::operator/=(const path& p)
{
if (p.empty())
@@ -629,7 +626,6 @@
{
namespace filesystem3
{
-
path::iterator path::begin() const
{
iterator itr;
@@ -682,7 +678,7 @@
# endif
)
{
- it.m_element.m_pathname = separator;
+ it.m_element.m_pathname = separator; // generic format; see docs
return;
}
@@ -738,8 +734,8 @@
it.m_pos = filename_pos(it.m_path_ptr->m_pathname, end_pos);
it.m_element = it.m_path_ptr->m_pathname.substr(it.m_pos, end_pos - it.m_pos);
- if (it.m_element.m_pathname == preferred_separator_string)
- it.m_element.m_pathname = separator_string; // needed for Windows, harmless on POSIX
+ if (it.m_element.m_pathname == preferred_separator_string) // needed for Windows, harmless on POSIX
+ it.m_element.m_pathname = separator_string; // generic format; see docs
}
} // namespace filesystem3
Modified: trunk/libs/filesystem/v3/test/path_unit_test.cpp
==============================================================================
--- trunk/libs/filesystem/v3/test/path_unit_test.cpp (original)
+++ trunk/libs/filesystem/v3/test/path_unit_test.cpp 2012-03-17 08:53:25 EDT (Sat, 17 Mar 2012)
@@ -976,9 +976,11 @@
// document state of critical macros
#ifdef BOOST_POSIX_API
cout << "BOOST_POSIX_API" << endl;
+ BOOST_TEST(path::preferred_separator == '/');
#endif
#ifdef BOOST_WINDOWS_API
cout << "BOOST_WINDOWS_API" << endl;
+ BOOST_TEST(path::preferred_separator == '\\');
#endif
l.push_back('s');
@@ -1021,7 +1023,7 @@
test_codecvt_argument();
test_error_handling();
-# if 0
+#if 0
test_user_supplied_type();