1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
<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=windows-1252">
<title>Do List</title>
<style type="text/css">
body { font-family: sans-serif; margin: 1em; }
p, td, li, blockquote { font-size: 10pt; }
pre { font-size: 9pt; }
</style>
</head>
<body>
<h1>Boost Filesystem Do List<br>
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B %Y" startspan -->24 June 2010<!--webbot bot="Timestamp" endspan i-checksum="17552" --></h1>
<h2>Beta 1 comments</h2>
<ul>
<li dir="ltr">
<p dir="ltr">Zach Laine:</li>
</ul>
<blockquote>
<pre dir="ltr">The descriptions for portable_name() and portable_directory_name()
appear to be at odds.
portable_name() : ... && (name is "." or "..", and the first character
not a period or hyphen)
portable_directory_name(): ... && (name is "." or ".." or contains no periods)
Should portable_name() be "... && (name is "." or "..", or contains no
periods) && (first character not a hyphen)"? Maybe I'm missing
something?</pre>
</blockquote>
<ul>
<li dir="ltr">
<p dir="ltr">Scott McMurray - treat as Wish List:</li>
</ul>
<blockquote>
<pre dir="ltr">- uncomplete(p, base)
My pet request. It may be useful to simplify other functions as well,
since there's no current way to go from an absolute path to a relative
one, meaning that most functions need to handle relative ones even
when that might not be natural. With this functionality,
preconditions requiring absolute paths would be less onerous.
Precondition: p.is_absolute() && base.is_absolute()
Effects: Extracts a path, rp, from p relative to base such that
canonical(p) == complete(rp, base). Any ".." path elements in rp form
a prefix.
Returns: The extracted path.
Postconditions: For the returned path, rp, rp.is_relative() ==
(p.root_name() == b.root_name()).
[Notes: This function simplifies paths by omitting context. It is
particularly useful for serializing paths such that it can be usefully
moved between hosts where the context may be different, such as inside
source control trees. It can also be helpful for display to users,
such as in shells where paths are often shown relative to $HOME.
In the presence of symlinks, the result of this function may differ
between implementations, as some may expand symlinks that others may
not. The simplest implementation uses canonical to expand both p and
base, then removes the common prefix and prepends the requisite ".."
elements. Smarter implementations will avoid expanding symlinks
unnecessarily. No implementation is expected to discover new symlinks
to return paths with fewer elements.]</pre>
</blockquote>
<h2 dir="ltr">Docs</h2>
<ul>
<li>Reorganize files - delete examples that no longer apply.</li>
<li>Should minimal.css be changed to used relative font sizes? See
<a href="http://www.w3schools.com/CSS/pr_font_font-size.asp/">http://www.w3schools.com/CSS/pr_font_font-size.asp\</a></li>
<li>Document behavior of path::replace_extension has change WRT argument w/o a
dot.</li>
<li style="font-size: 10pt">Document leading //: no longer treated specially.
But is that really correct?</li>
<li style="font-size: 10pt">Behavior of root_path() has been changed. Change
needs to be propagated to trunk?</li>
<li style="font-size: 10pt">Regenerate path decomposition table.</li>
</ul>
<h2>Code</h2>
<h3>All</h3>
<ul>
<li style="font-size: 10pt">Move semantics.</li>
<li style="font-size: 10pt">Use BOOST_DELETED, BOOST_DEFAULTED, where
appropriate.</li>
<li style="font-size: 10pt">Other C++0x features.</li>
</ul>
<h3>Class path</h3>
<ul>
<li>Windows, POSIX, conversions for char16_t, char32_t for C++0x compilers.</li>
<li>Add Windows Alternate Data Stream test cases. See http://en.wikipedia.org/wiki/NTFS
Features.</li>
<li>Add test case: relational operators on paths differing only in trailing
separator. Rationale?</li>
<li>Provide the name check functions for more character types? Templatize?
take a path argument?</li>
<li style="font-size: 10pt">Add codepage 936/950/etc test cases.</li>
<li style="font-size: 10pt">Should UDT's be supported?</li>
<li style="font-size: 10pt">Should path iteration to a separator result in:<br>
-- the actual separator used<br>
-- the preferred separator<br>
-- the generic separator <-- makes it easier to write portable code<br>
-- a dot</li>
</ul>
<h3>Operations</h3>
<ul>
<li>Would complete(), system_complete() be clearer if renamed absolute(),
absolute_system() (or absolute_native())?</li>
<li>Review all operations.cpp code for race conditions similar to #2925. Fix
or document.</li>
<li>Enable all BOOST_FILESYSTEM_NO_DEPRECATED code.</li>
<li>rename and remove names are problems. If users says "using
namespace boost::filesystem"<br>
and some header included stdio, there is just too much chance of silent error.</li>
<li>create_directories error handling needs work.</li>
<li>Fold convenience.hpp into operations.hpp</li>
<li>Two argument recursive_directory_iterator ctor isn't recognizing throws().
Would it be better to fold into a single two argument ctor with default?</li>
<li>Add the push_directory class from tools/release/required_files.cpp</li>
</ul>
<h3>Miscellaneous</h3>
<ul>
<li style="font-size: 10pt"><i>Regular</i> classes need hash functions.</li>
</ul>
<hr>
<p>© Copyright Beman Dawes, 2010</p>
<p>Distributed under 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>
|
