| Filesystem Library |
| Boost Home Library Home Tutorial Reference FAQ |
Some functions have been renamed or deprecated since earlier releases of the library. See Deprecated names and features.
Some library behavior is specified by reference to ISO/IEC 9945:2003, POSIX. How such behavior is actually implemented is unspecified.
[Note: This constitutes an "as if" rule for implementation of operating system dependent behavior. Presumably implementations will usually call native operating system API's. --end note]
Implementations are encouraged, but not required, to support such behavior as it is defined by POSIX. Implementations shall document any behavior that differs from the POSIX defined behavior. Implementations that do not support exact POSIX behavior are encouraged to provide behavior as close to POSIX behavior as is reasonable given the limitations of actual operating systems and file systems. If an implementation cannot provide any reasonable behavior, the implementation shall report an error in an implementation-defined manner.
[Note: Such errors might be reported by an #error directive, a
static_assert
, abasic_filesystem_error
exception, a special return value, or some other manner. --end note]
Specific operating systems such as OpenMVS, UNIX, and Windows are mentioned only for purposes of illustration or to give guidance to implementors. No slight to other operating systems is implied or intended.
The Effects and Postconditions of functions described in this reference may not be achieved in the presence of race conditions. No diagnostic is required.
If the possibility of race conditions makes it unreliable for a program to test for a precondition before calling a function described in this clause, Requires is not specified for the condition. Instead, the condition is specified as a Throws condition.
[Note: As a design practice, preconditions are not specified when it is unreasonable for a program to detect them prior to calling the function. -- end note]
The following definitions apply throughout this reference documentation:
File: An object that can be written to, or read from, or both. A file has certain attributes, including type. File types include regular file, symbolic link, and directory. Other types of files may be supported by the implementation.
File system: A collection of files and certain of their attributes.
Filename: The name of a file. The format is as specified by the POSIX Filename base definition.
Path: A sequence of elements which identify a location within a filesystem. The elements are the root-name, root-directory, and each successive filename. See Pathname grammar.
Pathname: A character string that represents a path.
Link: A directory entry object that associates a filename with a file. On some file systems, several directory entries can associate names with the same file.
Hard link: A link to an existing file. Some file systems support multiple hard links to a file. If the last hard link to a file is removed, the file itself is removed.
[Note: A hard link can be thought of as a shared-ownership smart pointer to a file. -- end note]
Symbolic link: A type of file with the property that when the file is encountered during pathname resolution, a string stored by the file is used to modify the pathname resolution.
[Note: A symbolic link can be thought of as a raw pointer to a file. If the file pointed to does not exist, the symbolic link is said to be a "dangling" symbolic link. -- end note]
Slash: The character '/', also known as solidus.
Dot: The character '.', also known as period.
Race condition: The condition that occurs when multiple threads, processes, or computers interleave access and modification of the same object within a file system.
The arguments for template parameters named Path
, Path1
,
or Path2
described in this clause shall be of type basic_path
,
or a class derived from basic_path
, unless otherwise
specified.
Some function templates described in this clause have a template parameter
named Path
, Path1
, or Path2
. When called
with a function argument s
of type char*
or
std::string
, the implementation shall treat the argument as if it were
coded path(s)
. When called with a function argument s
of type wchar_t*
or std::wstring
, the implementation
shall treat the argument as if it were coded wpath(s)
. For
functions with two arguments, implementations shall not supply this treatment
when Path1
and Path2
are different types.
[Note: This "do-the-right-thing" rule allows users to write
exists("foo")
, taking advantage of classbasic_path
's string conversion constructor, rather than the lengthier and more error proneexists(path("foo"))
. This is particularly important for the simple, script-like, programs which are an important use case for the library. Calling two argument functions with different types is a very rare usage, and may well be a coding error, so automatic conversion is not supported for such cases.The implementation technique is unspecified. One possible implementation technique, using
exists()
as an example, is:template <class Path> typename boost::enable_if<is_basic_path<Path>,bool>::type exists(const Path& p); inline bool exists(const path& p) { return exists<path>(p); } inline bool exists(const wpath& p) { return exists<wpath>(p); }The
enable_if
will fail for a C string orstd::basic_string
argument, which will then be automatically converted to abasic_path
object via the appropriatebasic_path
conversion constructor. -- end note]The two overloads are not given in the normative text because:
- Better techniques for achieving the desired affect may be developed, perhaps enabled by core language changes like Concepts.
- Implementations may prefer techniques that work with legacy compilers that do not support enable_if.
- Spelling out the overloads makes the text longer and harder to read without adding much benefit.
- More overloads will probably be needed for char16_t and char32_t (or whatever they end up being called), making it even less attractive to actually spell out each one.
Implementations of functions described in this clause are permitted to call the applications
program interface (API) provided by the operating system. If such an operating
system API call results in an error, implementations
shall report the error by throwing exception basic_filesystem_error
,
unless otherwise specified.
[Note: Such exceptions and the conditions that cause them to be thrown are not explicitly described in each Throws element within this clause. Because hardware failures, network failures, race conditions, and a plethora of other errors occur frequently in file system operations, users should be aware that unless otherwise specified any file system operation, not matter how apparently innocuous, may throw an exception. -- end note]
Functions commonly used in contexts
where errors are not exceptional have overloads taking an additional argument of
type error_code& ec
. Such overloaded functions shall not throw exceptions. If an error occurs,
ec
shall be set to the
error code reported by the operating system, otherwise ec
shall be set to 0. If
an overload without an argument of type
error_code& ec
returns void, the other overload (with an argument of type
error_code& ec
) returns an
error_code
with the value of ec.
<boost/filesystem>
synopsisnamespace boost { namespace filesystem { template <class String, class Traits> class basic_path; template<class String, class Traits> void swap(basic_path<String, Traits> & lhs, basic_path<String, Traits> & rhs); template<class String, class Traits> bool operator<(a a, b b); template<class String, class Traits> bool operator==(a a, b b); template<class String, class Traits> bool operator!=(a a, b b); template<class String, class Traits> bool operator>(a a, b b); template<class String, class Traits> bool operator<=(a a, b b); template<class String, class Traits> bool operator>=(a a, b b); template<class String, class Traits> bool operator/(a a, b b); template<class Path> basic_ostream<typename Path::string_type::value_type, typename Path::string_type::traits_type> & operator<<(basic_ostream<typename Path::string_type::value_type, typename Path::string_type::traits_type>& os, const Path & ph); template<class Path> basic_istream<typename Path::string_type::value_type, typename Path::string_type::traits_type> & operator>>(basic_istream<typename Path::string_type::value_type, typename Path::string_type::traits_type>& is, Path & ph); struct path_traits; struct wpath_traits; typedef basic_path<std::string, path_traits> path; typedef basic_path<std::wstring, wpath_traits> wpath; template<class Path> struct is_basic_path; template<class Path> struct slash { static const char value = '/'; }; template<class Path> struct dot { static const char value = '.'; }; template<class Path> struct colon { static const char value = ':'; }; class filesystem_error; template <class Path> class basic_filesystem_error; typedef basic_filesystem_error<path> filesystem_error; typedef basic_filesystem_error<wpath> wfilesystem_error; template <class Path> class basic_directory_entry; typedef basic_directory_entry<path> directory_entry; typedef basic_directory_entry<wpath> wdirectory_entry; template <class Path> class basic_directory_iterator; typedef basic_directory_iterator<path> directory_iterator; typedef basic_directory_iterator<wpath> wdirectory_iterator; template <class Path> class basic_recursive_directory_iterator; typedef basic_recursive_directory_iterator<path> recursive_directory_iterator; typedef basic_recursive_directory_iterator<wpath> wrecursive_directory_iterator; enum file_type { status_unknown, file_not_found, regular_file, directory_file, symlink_file, block_file, character_file, fifo_file, socket_file, type_unknown }; class file_status; struct space_info // returned by space function { uintmax_t capacity; uintmax_t free; uintmax_t available; }; // status functions template <class Path> file_status status(const Path& p); template <class Path> file_status status(const Path& p, error_code& ec); template <class Path> file_status symlink_status(const Path& p); template <class Path> file_status symlink_status(const Path& p, error_code& ec); // predicate functions bool status_known( file_status s ); bool exists( file_status s ); bool is_regular_file( file_status s ); bool is_directory( file_status s ); bool is_symlink( file_status s ); bool is_other( file_status s ); template <class Path> bool exists(const Path& p); template <class Path> bool is_directory(const Path& p); template <class Path> bool is_regular_file(const Path& p); template <class Path> bool is_other(const Path& p); template <class Path> bool is_symlink(const Path& p); template <class Path> bool is_empty(const Path& p); template <class Path1, class Path2> bool equivalent(const Path1& p1, const Path2& p2); // attribute functions template <class Path> Path current_path(); template <class Path> void current_path(const Path& p); template <class Path> const Path& initial_path(); template <class Path> uintmax_t file_size(const Path& p); template <class Path> space_info space(const Path& p); template <class Path> std::time_t last_write_time(const Path& p); template <class Path> void last_write_time(const Path& p, const std::time_t new_time); // operations functions template <class Path> bool create_directory(const Path& dp); template <class Path1, class Path2> void create_hard_link(const Path1& old_fp, const Path2& new_fp); template <class Path1, class Path2> error_code create_hard_link(const Path1& old_fp, const Path2& new_fp, error_code& ec); template <class Path1, class Path2> void create_symlink(const Path1& old_fp, const Path2& new_fp); template <class Path1, class Path2> error_code create_symlink(const Path1& old_fp, const Path2& new_fp, error_code& ec); template <class Path> bool remove(const Path& p); template <class Path1, class Path2> void rename(const Path1& from_p, const Path2& to_p); BOOST_SCOPED_ENUM_START(copy_option) { fail_if_exists, overwrite_if_exists }; BOOST_SCOPED_ENUM_END template <class Path1, class Path2> void copy_file(const Path1& from_fp, const Path2& to_fp, BOOST_SCOPED_ENUM(copy_option) option=copy_option::fail_if_exists); template <class Path> Path system_complete(const Path& p); template <class Path> Path complete(const Path& p, const Path& base=initial_path<Path>()); // convenience functions template <class Path> bool create_directories(const Path& p); template <class Path> typename Path::string_type extension(const Path& p); template <class Path> typename Path::string_type basename(const Path& p); template <class Path> Path change_extension(const Path& p, const typename Path::string_type& new_extension); } // namespace filesystem } // namespace boost
This subclause defines requirements on classes representing path behavior
traits, and defines two classes that satisfy those requirements for paths based
on string
and wstring
.. It also defines several path
additional path traits structure templates, and defines several specializations
of them.
Class template basic_path
defined in this clause requires additional
types, values, and behavior to complete the definition of its semantics.
For purposes of exposition, Traits behaves as if it is a class with private members bool m_locked, initialized false, and std::locale m_locale, initialized
| Path Behavior Traits Requirements | |
| Expression | Requirements |
Traits::external_string_type |
A typedef which is a specialization of basic_string .
The value_type is a character type used by the operating system
to represent pathnames. |
Traits::internal_string_type |
A typedef which is a specialization of basic_string .
The value_type is a character type to be used by the program to
represent pathnames. Required be the same type as the basic_path
String template parameter. |
Traits::to_external( p, is ) |
is , converted by the m_locale
codecvt facet to external_string_type . |
Traits::to_internal( p, xs ) |
xs , converted by the m_locale
codecvt facet to to internal_string_type . |
Traits::imbue(loc) |
Effects: if m_locked , throw. Otherwise,
m_locked = true; m_locale = loc; Returns: void Throws: basic_filesystem_error |
Traits::imbue(loc, std::nothrow) |
Effects: if (!m_locked) m_locale = loc; bool
temp(m_locked); m_locked = true; Returns: temp |
Type is_basic_path
shall be a UnaryTypeTrait (TR1, 4.1).
The primary template shall be derived directly or indirectly from
std::tr1::false_type
. Type is_basic_path
shall be
specialized for path
, wpath
, and any
user-specialized basic_path
types, and such specializations shall
be derived directly or indirectly from std::tr1::true_type
.
Structure templates slash
, dot
, and
colon
are supplied with
values of type char
. If a user-specialized basic_path
has a
value_type
type which is not convertible from char
, the
templates slash
and dot
shall be specialized to
provide value
with type which is convertible to
basic_path::value_type
.
basic_path
Class template basic_path
provides a portable mechanism for
representing paths in C++ programs, using a portable generic
pathname grammar. When portability is not a
requirement, native file system specific formats can be used. Class template
basic_path
is concerned only with the lexical and syntactic aspects
of a path. The path does not have to exist in the operating system's file
system, and may contain names which are not even valid for the current operating
system.
[Note: If the library's functions trafficked only in C++ or C-style strings, they would provide only the illusion of portability since while the syntax of function calls would be portable, the semantics of the strings they operate on would not be portable. -- end note]
namespace boost
{
namespace filesystem
{
template <class String, class Traits> class basic_path
{
public:
typedef basic_path<String, Traits> path_type;
typedef String string_type;
typedef typename String::value_type value_type;
typedef Traits traits_type;
typedef typename Traits::external_string_type external_string_type;
// constructors/destructor
basic_path();
basic_path(const basic_path& p);
basic_path(const string_type& s);
basic_path(const value_type* s);
template <class InputIterator>
basic_path(InputIterator first, InputIterator last);
~basic_path();
// assignments
basic_path& operator=(const basic_path& p);
basic_path& operator=(const string_type& s);
basic_path& operator=(const value_type* s);
template <class InputIterator>
basic_path& assign(InputIterator first, InputIterator last);
// modifiers
basic_path& operator/=(const basic_path& rhs);
basic_path& operator/=(const string_type& s);
basic_path& operator/=(const value_type* s);
template <class InputIterator>
basic_path& append(InputIterator first, InputIterator last);
void clear();
void swap( basic_path & rhs );
basic_path& remove_filename();
basic_path& replace_extension(const string_type & new_extension = "");
// observers
const string_type string() const;
const string_type file_string() const;
const string_type directory_string() const;
const external_string_type external_file_string() const;
const external_string_type external_directory_string() const;
string_type root_name() const;
string_type root_directory() const;
basic_path root_path() const;
basic_path relative_path() const;
basic_path parent_path() const;
string_type filename() const;
string_type stem() const;
string_type extension() const;
bool empty() const;
bool is_complete() const;
bool has_root_name() const;
bool has_root_directory() const;
bool has_root_path() const;
bool has_relative_path() const;
bool has_filename() const;
bool has_parent_path() const;
// iterators
class iterator;
typedef iterator const_iterator;
iterator begin() const;
iterator end() const;
};
} // namespace filesystem
} // namespace boost
A basic_path
object stores a possibly empty path.
The internal form of the stored path is unspecified.
Functions described in this clause which access files or their attributes do so by
resolving a basic_path
object into a particular file in a file
hierarchy. The pathname, suitably converted to the string type, format, and
encoding
required by the operating system, is resolved as if by the POSIX
Pathname Resolution mechanism. The encoding of the resulting pathname is determined by the Traits::to_external
conversion function.
[Note: There is no guarantee that the path stored in a
basic_path
object is valid for a particular operating system or file system. -- end note]
Some functions in this clause return basic_path
objects for
paths composed partly or wholly of pathnames obtained from the operating system.
Such pathnames are suitably converted from the actual format and string
type supplied by the operating system. The encoding of the resulting path is determined by the Traits::to_internal
conversion function.
For member functions described as returning "const string_type
" or
"const external_string_type
", implementations are permitted to return
"const string_type&
" or "const external_string_type&
"
respectively.
[Note: This allows implementations to avoid unnecessary copies. Return-by-value is specified as
const
to ensure programs won't break if moved to a return-by-reference implementation. -- end note]
There are two formats for string or sequence arguments that describe a path:
[Note: The POSIX format is the basis for the portable format because it is already an ISO standard, is the basis for the ubiquitous URL format, and is the native format or a subset of the native format for UNIX-like and Windows-like operating systems familiar to large numbers of programmers.
Use of the portable format does not alone guarantee portability; filenames must also be portable. See Filename conversions. Each operating system follows its own rules. Use of the portable format does not change that. -- end note]
[Note: If an operating system supports only the POSIX pathname format, the portable format and the native format are the same.
Identifying user-provided paths as native format is a common need, and ensures maximum portability, even though not strictly needed except on systems where the native format is not implicitly recognized.
Programs using hard-coding native formats are likely to be non-portable. -- end note]
All basic_path
string or sequence arguments that describe a
path shall accept the portable pathname format, and shall accept the native
format if explicitly identified by a native format escape sequence prefix of
slash slash colon
.
[Note:
slash slash colon
was chosen as the escape sequence because a leadingslash slash
is already implementation-defined by POSIX,colon
is prohibited in a Windows filename, and on any system a singleslash
can be used when a filename beginning with acolon
is desired. These factors eliminate the chance of collision with a real filename. -- end note]
Implementations are encouraged to implicitly recognize the native pathname format if it can be lexically identified. An implementation shall document whether or not the native pathname format is implicitly recognized.
[Example:
-- OpenVMS:
"SYS1::DISK1:[JANE.TYLER.HARRY]
" is treated as a native pathname with a system name, drive name, and three directory filenames, rather than a portable pathname with one filename.-- Windows:
"c:\\jane\\tyler\\harry"
is treated as a native pathname with a drive letter, root-directory, and three filenames, rather than a portable pathname with one filename.-- Counter-example 1: An operating system that allows slashes in filenames and uses dot as a directory separator. Distinguishing between portable and native format argument strings or sequences is not possible as there is no other distinguishing syntax. The implementation does not accept native format pathnames unless the
native
argument is present.-- Counter-example 2: An operating system that allows slashes in filenames and uses some unusual character as a directory separator. The implementation does accept native format pathnames without the additional
native
argument, which only has to be used for native format arguments containing slashes in filenames.-- end example]
[Note: This duck-rule ("if it looks like a duck, walks like a duck, and quacks like a duck, it must be a duck") eliminates format confusion as a source of programmer error and support requests. -- end note]
If both the portable and native formats are accepted, implementations shall document what characters or character sequences are used to distinguish between portable and native formats.
[Note: Windows implementations are encouraged to define colons and backslashes as the characters which distinguish native from portable formats. --end note]
The grammar for the portable pathname format is as follows:
pathname:
root-nameopt root-directoryopt relative-pathoptroot-name:
implementation-definedroot-directory:
slash
root-directory slash
implementation-definedrelative-path:
filename
relative-path slash
relative-path slash filenamefilename:
name
dot
dot dotslash:
slash<Path>::value
dot:
dot<Path>::value
The grammar is aligned with the POSIX Filename, Pathname and Pathname Resolution definitions. Any conflict between the grammar and POSIX is unintentional. This technical report defers to POSIX.
The form of the above wording was taken from POSIX, which uses it in several places to defer to the C standard.
[Note: Windows implementations are encouraged to define slash slash name as a permissible root-name. POSIX permits, but does not require, implementations to do the same. Windows implementations are encouraged to define an additional root-directory element root_directory name. It is applicable only to the slash slash name form of root-name.
Windows implementations are encouraged to recognize a name followed by a colon as a native format root-name, and a backslash as a format element equivalent to slash. -- end note]
When converting filenames to the native operating system format, implementations are encouraged, but not required, to convert otherwise invalid characters or character sequences to valid characters or character sequences. Such conversions are implementation-defined.
[Note: Filename conversion allows much wider portability of both programs and filenames that would otherwise be possible.
Implementations are encouraged to base conversion on existing standards or practice. Examples include the Uniform Resource Locator escape syntax of a percent sign (
'%'
) followed by two hex digits representing the character value. On OpenVMS, which does not allow percent signs in filenames, a dollar sign ('$'
) followed by two hex digits is the existing practice, as is converting lowercase letters to uppercase. -- end note.]The Boost implementation for Windows currently does not map invalid characters. Pending feedback from the LWG, Boost may settle on % hex hex as the preferred escape sequence. If so, should there be normative encouragement?
The argument for the template parameter named String
shall be a
class that includes members with the same names, types, values, and semantics as
class template basic_string
.
The argument for the template parameter named Traits
shall be a
class that satisfies the requirements specified in the
Path Behavior Traits Requirements
table.
The argument for template parameters named InputIterator
shall satisfy the
requirements of an input iterator (C++ Std, 24.1.1, Input iterators [lib.input.iterators]) and shall have a value type convertible to
basic_path::value_type
.
Some function templates with a template
parameter named InputIterator
also have non-template overloads. Implementations shall
only select the function template overload if the type named by InputIterator
is not path_format_t
.
[Note: This "do-the-right-thing" rule ensures that the overload expected by the user is selected. The implementation technique is unspecified - implementations may use enable_if or other techniques to achieve the effect. -- end note]
basic_path
constructorsbasic_path();
Postconditions:
empty()
.
basic_path(const string_type& s); basic_path(const value_type * s); template <class InputIterator> basic_path(InputIterator s, InputIterator last);
Remarks: The format of string
s
and sequence [first
,last
) is described in Pathname formats.Effects: The path elements in string
s
or sequence [first
,last
) are stored.
basic_path
assignmentsbasic_path& operator=(const string_type& s); basic_path& operator=(const value_type* s); template <class InputIterator> basic_path& assign(InputIterator first, InputIterator last);
Remarks: The format of string
s
and sequence [first
,last
) is described in Pathname formats.Effects: The path elements in string
s
or sequence [first
,last
) are stored.Returns:
*this
basic_path
modifiersbasic_path& operator/=(const basic_path& rhs);
Effects: The path stored in
rhs
is appended to the stored path.Returns:
*this
basic_path& operator/=(const string_type& s); basic_path& operator/=(const value_type* s); template <class InputIterator> basic_path& append(InputIterator first, InputIterator last);
Remarks: The format of string
s
and sequence [first
,last
) is described in Pathname formats.Effects: The path elements in string
s
or sequence [first
,last
) are appended to the stored path.Returns:
*this
void clear();
Postcondition:
this->empty()
is true.
void swap( basic_path & rhs );
Effects: Swaps the contents of the two paths.
Throws: nothing.
Postcondition:
this->string()
contains the same sequence of characters that were inrhs.string()
,rhs.string()
contains the same sequence of characters that were isthis->string()
.Complexity: constant time.
basic_path& remove_filename();
Effects: If
has_parent_path()
then remove the last filename from the stored path. If that leaves the stored path with one or more trailing slash elements not representing root-directory, remove them.Returns:
*this
[Note: This function is needed to efficiently implement
basic_directory_iterator
. It is made public to allow additional uses. -- end note]
basic_path& replace_extension( const string_type & new_extension = "" );
Postcondition:
extension() == replacement
, wherereplacement
isnew_extension
ifnew_extension.empty() || new_extension[0] ==
the dot character, otherwisereplacement
is the dot character followed bynew_extension
.Returns:
*this
basic_path
observersSee the Path decomposition table for examples for values returned by decomposition functions.
const string_type string() const;
Returns: The stored path, formatted according to the Pathname grammar rules.
const string_type file_string() const;
Returns: The stored path, formatted according to the operating system rules for regular file pathnames, with any Filename conversion applied.
[Note: For some operating systems, including POSIX and Windows, the native format for regular file pathnames and directory pathnames is the same, so
file_string()
anddirectory_string()
return the same string. On OpenMVS, however, the expressionpath("/cats/jane").file_string()
would return the string"[CATS]JANE"
whilepath("/cats/jane").directory_string()
would return the string"[CATS.JANE]"
. -- end note]
const string_type directory_string() const;
Returns: The stored path, formatted according to the operating system rules for directory pathnames, with any Filename conversion applied.
const external_string_type external_file_string() const;
Returns: The stored path, formatted according to the operating system rules for regular file pathnames, with any Filename conversion applied, and encoded by the
Traits::to_external
conversion function.
const external_string_type external_directory_string() const;
Returns: The stored path, formatted according to the operating system rules for directory pathnames, with any Filename conversion applied, and encoded by the
Traits::to_external
conversion function.
string_type root_name() const;
Returns: root-name, if the stored path includes root-name, otherwise
string_type()
.
string_type root_directory() const;
Returns: root-directory, if the stored path includes root-directory, otherwise
string_type()
.If root-directory is composed slash name, slash is excluded from the returned string.
basic_path root_path() const;
Returns:
root_name() / root_directory()
basic_path relative_path() const;
Returns: A
basic_path
composed from the the stored path, if any, beginning with the first filename after root-path. Otherwise, an emptybasic_path
.
string_type filename() const;
Returns:
empty() ? string_type() : *--end()
basic_path parent_path() const;
Returns:
(string().empty() || begin() == --end()) ? path_type("") : br
, wherebr
is constructed as if by starting with an emptybasic_path
and successively applyingoperator/=
for each element in the rangebegin()
,--end()
.
string_type stem(const Path & p) const;
Returns: if
p.filename()
contains a dot, returns the substring ofp.filename()
starting at its beginning and ending at the last dot (the dot is not included). Otherwise, returnsp.filename()
.
string_type extension(const Path & p) const;
Returns: if
p.filename()
contains a dot, returns the substring ofp.filename()
starting at the rightmost dot and ending at the string's end. Otherwise, returns an empty string.[Note: The dot is included in the return value so that it is possible to distinguish between no extension and an empty extension.
Implementations are permitted but not required to define additional behavior for file systems which append additional elements to extensions, such as alternate data stream or partitioned dataset names. -- end note]
bool empty() const;
Returns:
string().empty()
.
bool is_complete() const;
Returns:
true
, if the elements of root_path() uniquely identify a directory, elsefalse
.
bool has_root_path() const;
Returns:
!root_path().empty()
bool has_root_name() const;
Returns:
!root_name().empty()
bool has_root_directory() const;
Returns:
!root_directory().empty()
bool has_relative_path() const;
Returns:
!relative_path().empty()
bool has_filename() const;
Returns:
!filename().empty()
bool has_parent_path() const;
Returns:
!parent_path().empty()
basic_path
iterators A basic_path::iterator
is a constant iterator satisfying all
the requirements of a bidirectional iterator (C++ Std, 24.1.4 Bidirectional
iterators [lib.bidirectional.iterators]). Its value_type
is
string_type
.
Calling any non-const member function of a basic_path
object
invalidates all iterators referring to elements of the object.
The forward traversal order is as follows:
The backward traversal order is the reverse of forward traversal.
iterator begin() const;
Returns: An iterator for the first present element in the traversal list above. If no elements are present, the end iterator.
iterator end() const;
Returns: The end iterator.
template<class String, class Traits>
void swap( basic_path<String, Traits> & lhs, basic_path<String, Traits> & rhs )
Effects:
lhs.swap( rhs )
There are seven basic_path non-member operators (/,
==
,
!=
,
<
,
>
,
<=
,
>=
),
each with five overloads. For brevity, the specifications are given in tabular
form. Each of the resulting thirty-five signatures is a template, with
template parameter list template<class
String, class Traits>
.
The format of such arguments is described in
Pathname formats.
|
Argument type overloads |
basic_path<String, Traits>& a, basic_path<String, Traits>&
b |
const
typename basic_path<String, Traits>::string_type& a,
basic_path<String, Traits>& b |
const
typename basic_path<String, Traits>::string_type::value_type* a,
basic_path<String, Traits>& b |
const
basic_path<String, Traits>& a, typename basic_path<String, Traits>::string_type&
b |
const
basic_path<String, Traits>& a, typename
basic_path<String, Traits>::string_type::value_type* b |
In the
basic_path non-member operators
table,
a
and b
are of the types given in the
Argument type overloads
table. If a
or b
is of type const
basic_path<String, Traits>&
,
then a'
or b'
respectively is a
or b
respectively. Otherwise a'
or b'
respectively represent named or unnamed temporary
basic_path<String, Traits>
objects constructed from
a
or
b
respectively.
| basic_path non-member operators | ||
| Expression | Return type | Semantics |
a / b |
basic_path<String, Traits> |
basic_path<String, Traits> tmp(a); b'; |
a < b |
bool |
return lexicographical_compare( a'.begin(),
a'.end(),
b'.begin(),
b'.end()); |
a == b |
bool |
return !( a'
< b')
&& !( b'
< a'); |
a != b |
bool |
return !( a'
== b'); |
a > b |
bool |
return b'
< a'; |
a <= b |
bool |
return !( b'
< a'); |
a >= b |
bool |
return !( a'
< b'); |
[Note: Path equality and path equivalence have different semantics.
Equality is determined by basic_path's non-member
operator==
, which considers the two path's lexical representations only. Paths "abc" and "ABC" are never equal.Equivalence is determined by the equivalent() non-member function, which determines if two paths resolve to the same file system entity. Paths "abc" and "ABC" may or may not resolve to the same file, depending on the file system.
Programmers wishing to determine if two paths are "the same" must decide if "the same" means "the same representation" or "resolve to the same actual file", and choose the appropriate function accordingly. -- end note]
basic_path
inserter
and extractortemplate<class Path>
basic_istream<typename Path::string_type::value_type, typename Path::string_type::traits_type>&
operator>>(basic_istream< typename Path::string_type::value_type, typename Path::string_type::traits_type>& is,
Path& ph );
Effects:
typename Path::string_type str;
is >> str;
ph = str;Returns:
is
template<class Path>
basic_ostream<typename Path::string_type::value_type, typename Path::string_type::traits_type>&
operator<<(basic_ostream< typename Path::string_type::value_type, typename Path::string_type::traits_type>& os,
const Path& ph );
Effects:
os << ph.string()
Returns:
os
basic_filesystem_error
namespace boost { namespace filesystem { template <class Path> class basic_filesystem_error : public system_error { public: typedef Path path_type; explicit basic_filesystem_error(const std::string& what_arg, error_code ec); basic_filesystem_error(const std::string& what_arg, const path_type& p1, error_code ec); basic_filesystem_error(const std::string& what_arg, const path_type& p1, const path_type& p2, error_code ec); const path_type& path1() const; const path_type& path2() const; const char * what() const; }; } // namespace filesystem } // namespace boost
The class template basic_filesystem_error
defines the type of
objects thrown as exceptions to report file system errors from functions described in this
clause.
basic_filesystem_error
constructorsexplicit basic_filesystem_error(const std::string& what_arg, error_code ec);
Postconditions:
Expression Value runtime_error::what()
what_arg.c_str()
code()
ec
path1().empty()
true
path2().empty()
true
basic_filesystem_error(const std::string& what_arg, const path_type& p1, error_code ec);
Postconditions:
Expression Value runtime_error::what()
what_arg.c_str()
code()
ec
path1()
Reference to stored copy of p1
path2().empty()
true
basic_filesystem_error(const std::string& what_arg, const path_type& p1, const path_type& p2, error_code ec);
Postconditions:
Expression Value runtime_error::what()
w
hat_arg.c_str()
code()
ec
path1()
Reference to stored copy of p1
path2()
Reference to stored copy of p2
basic_filesystem_error
observersconst path_type& path1() const;
Returns: Reference to copy of
p1
stored by the constructor, or, if none, an empty path.
const path_type& path2() const;
Returns: Reference to copy of
p2
stored by the constructor, or, if none, an empty path.
const char * what() const;
Returns: A string containing
runtime_error::what()
and the result of callingsystem_message()
with a first argument ofcode()
. The exact format is unspecified.The implementation shall supply a specialization
template<> const char * basic_filesystem_error<path>::what() const
that returns a string containingruntime_error::what(),
the result of callingsystem_message()
with a first argument ofcode()
, and if non-empty,path1().file_string()
andpath2.file_string()
. The exact format is unspecified.Implementations and users are permitted to provide other specializations of the
what
member function.
basic_directory_entry
namespace boost { namespace filesystem { template <class Path> class basic_directory_entry { public: typedef Path path_type; typedef typename Path::string_type string_type; // constructors basic_directory_entry(); explicit basic_directory_entry(const path_type& p, file_status st=file_status(), file_status symlink_st=file_status()); // modifiers void assign(const path_type& p, file_status st=file_status(), file_status symlink_st=file_status()); void replace_filename(const string_type& s, file_status st=file_status(), file_status symlink_st=file_status()); // observers const Path& path() const; operator const Path&() const; file_status status() const; file_status status(error_code& ec) const; file_status symlink_status() const; file_status symlink_status(error_code& ec) const; // comparisons bool operator<(const basic_directory_entry<Path>& rhs); bool operator==(const basic_directory_entry<Path>& rhs); bool operator!=(const basic_directory_entry<Path>& rhs); bool operator>(const basic_directory_entry<Path>& rhs); bool operator<=(const basic_directory_entry<Path>& rhs); bool operator>=(const basic_directory_entry<Path>& rhs); private: path_type m_path; // for exposition only mutable file_status m_status; // for exposition only; stat()-like mutable file_status m_symlink_status; // for exposition only; lstat()-like }; } // namespace filesystem } // namespace boost
A basic_directory_entry
object stores a basic_path object
,
a file_status
object for non-symbolic link status, and a
file_status
object for symbolic link status. The file_status
objects act as value caches.
[Note: Because
status()
on a pathname may be a very expensive operation, some operating systems provide status information as a byproduct of directory iteration. Caching such status information can result is significant time savings. Cached and non-cached results may differ in the presence of race conditions. -- end note]Actual cold-boot timing of iteration over a directory with 15,047 entries was six seconds for non-cached status queries versus one second for cached status queries. Windows XP, 3.0 GHz processor, with a moderately fast hard-drive. Similar speedup expected on Linux and BSD-derived Unix variants that provide status during directory iteration.
basic_directory_entry
constructorsbasic_directory_entry();
Postconditions:
Expression Value path().empty()
true
status()
file_status()
symlink_status()
file_status()
explicit basic_directory_entry(const path_type& p, file_status st=file_status(), file_status symlink_st=file_status());
Postconditions:
Expression Value path()
p
status()
st
symlink_status()
symlink_st
basic_directory_entry
modifiersvoid assign(const path_type& p, file_status st=file_status(), file_status symlink_st=file_status());
Postconditions:
Expression Value path()
p
status()
st
symlink_status()
symlink_st
void replace_filename(const string_type& s, file_status st=file_status(), file_status symlink_st=file_status());
Postconditions:
Expression Value path()
path().branch() / s
status()
st
symlink_status()
symlink_st
basic_directory_entry
observersconst Path& path() const; operator const Path&() const;
Returns:
m_path
file_status status() const;
Effects: As if,
if ( !status_known( m_status ) ) { if ( status_known(m_symlink_status) && !is_symlink(m_symlink_status) ) { m_status = m_symlink_status; } else { m_status = status(m_path); } }
Throws: See
status
function.Returns:
m_status
file_status status(error_code& ec) const;
Effects: As if,
if ( !status_known( m_status ) ) { if ( status_known(m_symlink_status) && !is_symlink(m_symlink_status) ) { m_status = m_symlink_status; } else { m_status = status(m_path, ec); } } else ec = 0;
Returns:
m_status
file_status symlink_status() const;
Effects: As if,
if ( !status_known( m_symlink_status ) ) { m_symlink_status = symlink_status(m_path); }
Throws: See
symlink_status
function.Returns:
m_symlink_status
file_status symlink_status(error_code& ec) const;
Effects: As if,
if ( !status_known( m_symlink_status ) ) { m_symlink_status = symlink_status(m_path, ec); } else ec = 0;
Returns:
m_symlink_status
basic_directory_iterator
namespace boost { namespace filesystem { template <class Path> class basic_directory_iterator : public iterator<input_iterator_tag, basic_directory_entry<Path> > { public: typedef Path path_type; // constructors basic_directory_iterator(); explicit basic_directory_iterator(const Path& dp); basic_directory_iterator(const Path& dp, error_code& ec); basic_directory_iterator(const basic_directory_iterator& bdi); basic_directory_iterator& operator=(const basic_directory_iterator& bdi); ~basic_directory_iterator(); // other members as required by // C++ Std, 24.1.1 Input iterators [lib.input.iterators] }; } // namespace filesystem } // namespace boost
basic_directory_iterator
satisfies the requirements of an
input iterator (C++ Std, 24.1.1, Input iterators [lib.input.iterators]).
A basic_directory_iterator
reads successive elements from the directory for
which it was constructed, as if by calling POSIX
readdir_r()
. After a basic_directory_iterator
is constructed, and every time
operator++
is called,
it reads and stores a value of basic_directory_entry<Path>
and possibly stores associated status values.
operator++
is not equality preserving; that is, i == j
does not imply that
++i == ++j
.
[Note: The practical consequence of not preserving equality is that directory iterators can be used only for single-pass algorithms. --end note]
If the end of the directory elements is reached, the iterator becomes equal to
the end iterator value. The constructor basic_directory_iterator()
with no arguments always constructs an end iterator object, which is the only
legitimate iterator to be used for the end condition. The result of
operator*
on an end iterator is not defined. For any other iterator value
a const basic_directory_entry<Path>&
is returned. The result of
operator->
on an end iterator is not defined. For any other
iterator value a const basic_directory_entry<Path>*
is
returned.
Two end iterators are always equal. An end iterator is not equal to a non-end iterator.
The above wording is based on the Standard Library's istream_iterator wording. Commentary was shortened and moved into a note.
The result of calling the path()
member of the
basic_directory_entry
object obtained by dereferencing a
basic_directory_iterator
is a reference to a basic_path
object composed of the directory argument from which the iterator was
constructed with filename of the directory entry appended as if by
operator/=
.
[Example: This program accepts an optional command line argument, and if that argument is a directory pathname, iterates over the contents of the directory. For each directory entry, the name is output, and if the entry is for a regular file, the size of the file is output.
#include <iostream> #include <filesystem> using std::tr2::sys; using std::cout; int main(int argc, char* argv[]) { std::string p(argc <= 1 ? "." : argv[1]); if (is_directory(p)) { for (directory_iterator itr(p); itr!=directory_iterator(); ++itr) { cout << itr->path().filename() << ' '; // display filename only if (is_regular_file(itr->status())) cout << " [" << file_size(itr->path()) << ']'; cout << '\n'; } } else cout << (exists(p) ? "Found: " : "Not found: ") << p << '\n'; return 0; }-- end example]
Directory iteration shall not yield directory entries for the current (dot) and parent (dot dot) directories.
The order of directory entries obtained by dereferencing successive
increments of a basic_directory_iterator
is unspecified.
[Note: Programs performing directory iteration may wish to test if the path obtained by dereferencing a directory iterator actually exists. It could be a symbolic link to a non-existent file. Programs recursively walking directory trees for purposes of removing and renaming entries may wish to avoid following symbolic links.
If a file is removed from or added to a directory after the construction of a
basic_directory_iterator
for the directory, it is unspecified whether or not subsequent incrementing of the iterator will ever result in an iterator whose value is the removed or added directory entry. See POSIXreaddir_r()
. --end note]
basic_directory_iterator
constructorsbasic_directory_iterator();
Effects: Constructs the end iterator.
explicit basic_directory_iterator(const Path& dp);
Effects: Constructs a iterator representing the first entry in the directory resolved to by
dp
, otherwise, the end iterator.[Note: To iterate over the current directory, write
directory_iterator(".")
rather thandirectory_iterator("")
. -- end note]
basic_directory_iterator(const Path& dp, error_code& ec );
Effects: Constructs a iterator representing the first entry in the directory resolved to by
dp
, otherwise, the end iterator. If an error occurs while establishing the results, the iterator constructed represents the end iterator andec
is set to the error code reported by the operating system, otherwise to 0.
basic_recursive_directory_iterator
namespace boost { namespace filesystem { template <class Path> class basic_recursive_directory_iterator : public iterator<input_iterator_tag, basic_directory_entry<Path> > { public: typedef Path path_type; // constructors basic_recursive_directory_iterator(); explicit basic_recursive_directory_iterator(const Path& dp); basic_recursive_directory_iterator(const basic_recursive_directory_iterator& brdi); basic_recursive_directory_iterator& operator=(const basic_recursive_directory_iterator& brdi); ~basic_recursive_directory_iterator(); // observers int level() const; // modifiers void pop(); void no_push(); // other members as required by // C++ Std, 24.1.1 Input iterators [lib.input.iterators] private: int m_level; // for exposition only }; } // namespace filesystem } // namespace boost
The behavior of a basic_recursive_directory_iterator
is the same
as a basic_directory_iterator
unless otherwise specified.
m_level
is set to 0;it
is incremented, if it->is_directory()
is true and no_push()
had not been called subsequent to
the most recent increment operation (or construction, if no increment has
occurred), then m_level
is incremented, the
directory is visited, and its contents recursively iterated over.pop()
is called, m_level
is
decremented, and iteration continues with the parent directory, until the
directory specified in the constructor argument is reached.level()
returns m_level
.level()
, pop()
, and no_push()
all
require that the iterator not be the end iterator.[Note: One of the uses of
no_push()
is to prevent unwanted recursion into symlinked directories. This may be necessary to prevent loops on some operating systems. --end note]
namespace boost { namespace filesystem { class file_status { public: explicit file_status( file_type v = status_unknown ); file_type type() const; void type( file_type v ); }; } // namespace filesystem } // namespace boost
A file_status
object stores information about the status of a
file. The internal form of the stored information is unspecified.
[Note: The class may be extended in the future to store additional status information. --end note]
explicit file_status( file_type v = status_unknown );
Effects: Stores
v
.
file_type type() const;
Returns: The stored
file_type
.
void type( file_type v );
Effects: Stores
v
, replacing the previously stored value.
template <class Path> file_status status(const Path& p, error_code& ec); template <class Path> file_status symlink_status(const Path& p, error_code& ec);
Returns:
Forstatus
, determine the attributes ofp
as if by POSIXstat()
, forsymlink_status
, determine the attributes as if by POSIXlstat()
.[Note: For symbolic links,
stat()
continues pathname resolution using the contents of the symbolic link,lstat()
does not. -- end note]If the underlying file system reports an error during attribute determination:
- If the error indicating that
p
could not be resolved, as if by POSIX errors ENOENT or ENOTDIR, callec.clear()
and returnfile_status(not_found_flag)
.[Note: The effect of this behavior is to distinguish between knowing that p does not exist, and not being able to determine the status of p. This distinction is important to users. --end note]
Otherwise:
- Otherwise, set ec to the error number reported by the underlying implementation API and return
file_status(status_unknown)
.
- If the attributes indicate a regular file, as if by POSIX S_ISREG(), return
file_status(regular_file)
.- Else if the attributes indicate a directory, as if by POSIX S_ISDIR(), return
file_status(directory_file)
.- Else if the attributes indicate a symbolic link, as if by POSIX S_ISLNK(), return
file_status(symlink_file)
. [Note: Only possible forsymlink_status
. --end note]- Else if the attributes indicate a block special file, as if by POSIX S_ISBLK(), return
file_status(block_file)
.- Else if the attributes indicate a character special file, as if by POSIX S_ISCHR(), return
file_status(character_file)
.- Else if the attributes indicate a fifo or pipe file, as if by POSIX S_ISFIFO(), return
file_status(fifo_file)
.- Else if the attributes indicate a socket, as if by POSIX S_ISSOCK(), return
file_status(socket_file)
.- Else return
file_status(type_unknown)
.[Note:
directory_file
impliesbasic_directory_iterator
on the file would succeed, andregular_file
implies appropriate<fstream>
operations would succeed, assuming no hardware, permission, access, or race condition errors. Forregular_file,
the converse is not true; lack ofregular_file
does not necessarily imply<fstream>
operations would fail on a directory. -- end note]
template <class Path> file_status status(const Path& p);
Effects:
system_error_code ec;
file_status stat(status(p, ec));
Throws:
basic_filesystem_error<Path>
ifec != 0
Returns:
stat
template <class Path> file_status symlink_status(const Path& p);
Effects:
system_error_code ec;
file_status stat(symlink_status(p, ec));
Throws:
basic_filesystem_error<Path>
ifec != 0
Returns:
stat
bool status_known(file_status s);
Returns:
s.type() != status_unknown
bool exists(file_status s);
Returns:
status_known(s) && s.type() != file_not_found
template <class Path> bool exists(const Path& p);
Returns:
exists( status(p) )
bool is_regular_file
(file_status s);
Returns:
s.type() == regular_file
template <class Path> bool is_regular_file(const Path& p);
Returns:
is_regular_file( status(p) )
bool is_directory
(file_status s);
Returns:
s.type() == directory_file
template <class Path> bool is_directory(const Path& p);
Returns:
is_directory( status(p) )
bool is_symlink(file_status s);
Returns:
s.type() == symlink_file
template <class Path> bool is_symlink(const Path& p);
Returns:
is_symlink( symlink_status(p) )
bool is_other(file_status s);
Returns:
return exists(s) && !is_regular_file(s) && !is_directory(s) && !is_symlink(s)
[Note: The specification of
is_other()
will remain unchanged even if additionalis_xxx()
functions are added in the future. -- end note]
template <class Path> bool is_other(const Path& p);
Returns:
is_other( status(p) )
template <class Path> bool is_empty(const Path& p);
Effects: Determines
file_status s
, as if bystatus(p)
.Throws:
basic_filesystem_error<Path>
if!exist(s) || is_other(s)
.Returns:
is_directory(s)
? basic_directory_iterator<Path>(p) == basic_directory_iterator<Path>()
: file_size(p) == 0;
template <class Path1, class Path2> bool equivalent(const Path1& p1, const Path2& p2);
Requires:
Path1::external_string_type
andPath2::external_string_type
are the same type.Effects: Determines
file_status s1
ands2
, as if bystatus(p1)
andstatus(p2)
, respectively.Throws:
basic_filesystem_error<Path1>
if(!exists(s1) && !exists(s2)) || (is_other(s1) && is_other(s2))
.Returns:
true
, ifsf1 == sf2
andp1
andp2
resolve to the same file system entity, elsefalse
.Two paths are considered to resolve to the same file system entity if two candidate entities reside on the same device at the same location. This is determined as if by the values of the POSIX
stat
structure,
obtained as if bystat()
for the two paths, having equalst_dev
values and equalst_ino
values.[Note: POSIX requires that "st_dev must be unique within a Local Area Network". Conservative POSIX implementations may also wish to check for equal
st_size
andst_mtime
values. Windows implementations may useGetFileInformationByHandle()
as a surrogate forstat()
, and consider "same" to be equal values fordwVolumeSerialNumber
,nFileIndexHigh
,nFileIndexLow
,nFileSizeHigh
,nFileSizeLow
,ftLastWriteTime.dwLowDateTime
, andftLastWriteTime.dwHighDateTime
. -- end note]
[Note: A strictly limited number of attribute functions are provided because few file system attributes are portable. Even the functions provided will be impossible to implement on some file systems. --end note.]
template <class Path> const Path& initial_path();
Returns:
current_path()
at the time of entry tomain()
.[Note: These semantics turn a dangerous global variable into a safer global constant. --end note]
[Note: Full implementation requires runtime library support. Implementations which cannot provide runtime library support are encouraged to instead store the value of
current_path()
at the first call ofinitial_path
()
, and return this value for all subsequent calls. Programs usinginitial_path
()
are encouraged to call it immediately on entrance tomain()
so that they will work correctly with such partial implementations. --end note]
template <class Path> Path current_path();
Returns: The current path, as if by POSIX
getcwd()
.Postcondition:
current_path().is_complete()
[Note: The current path as returned by many operating systems is a dangerous global variable. It may be changed unexpectedly by a third-party or system library functions, or by another thread. Although dangerous, the function is useful in dealing with other libraries.. For a safer alternative, see
initial_path()
. Thecurrent_path()
name was chosen to emphasize that the return is a complete path, not just a single directory name. -- end note]
template <class Path> void current_path(const Path& p);
Postcondition: equivalent( p, current_path() );
template <class Path> uintmax_t file_size(const Path& p);
Returns: The size in bytes of the file
p
resolves to, determined as if by the value of the POSIXstat
structure memberst_size
obtained as if by POSIXstat()
.
template <class Path> space_info space(const Path& p);
Returns: A
space_info
object. The value of thespace_info
object is determined as if by using POSIXstatvfs()
to obtain a POSIX structstatvfs
, and then multiplying itsf_blocks
,f_bfree
, andf_bavail
members by itsf_frsize
member, and assigning the results to thecapacity
,free
, andavailable
members respectively. Any members for which the value cannot be determined shall be set to -1.
template <class Path> std::time_t last_write_time(const Path& p);
Returns: The time of last data modification of
p
, determined as if by the value of the POSIXstat
structure memberst_mtime
obtained as if by POSIXstat()
.
template <class Path> void last_write_time(const Path& p, const std::time_t new_time);
Effects: Sets the time of last data modification of the file resolved to by
p
tonew_time
, as if by POSIXstat()
followed by POSIXutime()
.[Note: The apparent postcondition
last_write_time(p) == new_time
is not specified since it would not hold for many file systems due to coarse time mechanism granularity. -- end note]
template <class Path> bool create_directory(const Path& dp);
Effects: Attempts to create the directory
dp
resolves to, as if by POSIXmkdir()
with a second argument of S_IRWXU|S_IRWXG|S_IRWXO.Throws:
basic_filesystem_error<Path>
if Effects fails for any reason other than because the directory already exists.Returns: True if a new directory was created, otherwise false.
Postcondition:
is_directory(dp)
template <class Path1, class Path2>
error_code create_hard_link(const Path1& to_p, const Path2& from_p, error_code& ec);
Requires:
Path1::external_string_type
andPath2::external_string_type
are the same type.Effects: Establishes the postcondition, as if by POSIX
link()
.Returns: If the postcondition cannot be established, a system error code indicating the reason for the failure, otherwise 0.
Postcondition:
exists(to_p) && exists(from_p) && equivalent(to_p, from_p)
- The contents of the file or directory
to_p
resolves to are unchanged.[Note: Some operating systems do not support hard links or support them only for regular files. Some operating systems limit the number of links per file. Some file systems that do not support hard links - the FAT system used on floppy discs, memory cards and flash drives, for example. Thus hard links should be avoided if wide portability is a concern. -- end note]
template <class Path1, class Path2>
void create_hard_link(const Path1& to_p, const Path2& from_p);
Requires:
Path1::external_string_type
andPath2::external_string_type
are the same type.Effects: As if
system_error_code ec( create_hard_link( to_p, from_p ) );
Throws:
basic_filesystem_error<Path1, Path2>
ifec
is not zero.
template <class Path1, class Path2>
error_code create_symlink(const Path1& to_p, const Path2& from_p, error_code& ec);
Requires:
Path1::external_string_type
andPath2::external_string_type
are the same type.Effects: Establishes the postcondition, as if by POSIX
symlink()
.Returns: If the postcondition cannot be established, a system error code indicating the reason for the failure, otherwise 0.
Postcondition:
from_p
resolves to a symbolic link file that contains an unspecified representation ofto_p
.[Note: Some operating systems do not support symbolic links at all or support them only for regular files. Thus symbolic links should be avoided if code portability is a concern. -- end note]
template <class Path1, class Path2>
void create_symlink(const Path1& to_p, const Path2& from_p);
Requires:
Path1::external_string_type
andPath2::external_string_type
are the same type.Effects: As if
system_error_code ec( create_symlink( to_p, from_p ) );
Throws:
basic_filesystem_error<Path1, Path2>
ifec
is not zero.
template <class Path> bool remove(const Path& p, system::error_code & ec = singular );
Effects: Removes the file
p
, as if by POSIXremove()
. If no error is reported by the underlying removal implementation or ifstatus(p).type() == file_not_found
, then:
- if
ec !=
singular
, thenec.clear()
.Otherwise,
- if
ec !=
singular
, then setec
to represent the error.- otherwise, throw
basic_filesystem_error<Path>
to represent the error.ifec !=
singular
, thenec.clear()
Returns:
true
if the file was removed, otherwisefalse
.Postcondition:
!exists(p)
Throws: See Effects.
[Note: A symbolic link is itself removed, rather than the file it resolves to being removed. -- end note]
template <class Path> unsigned long remove_all(const Path& p);
Effects: Recursively deletes the contents of p if it exists, then deletes file
p
itself, as if by POSIXremove()
.Returns: The number of files removed.
Postcondition:
!exists(p)
[Note: A symbolic link is itself removed, rather than the file it resolves to being removed. -- end note]
template <class Path1, class Path2> void rename(const Path1& from_p, const Path2& to_p);
Requires:
Path1::external_string_type
andPath2::external_string_type
are the same type.Effects: Renames
from_p
toto_p
, as if by POSIXrename()
.Postconditions:
!exists(from_p) && exists(to_p)
, and the contents and attributes of the file originally namedfrom_p
are otherwise unchanged.[Note: If
from_p
andto_p
resolve to the same file, no action is taken. Otherwise, ifto_p
resolves to an existing file, it is removed. A symbolic link is itself renamed, rather than the file it resolves to being renamed. -- end note]
template <class Path1, class Path2> void copy_file(const Path1& from_fp, const Path2& to_fp, BOOST_SCOPED_ENUM(copy_option) option=copy_option::fail_if_exists);
Requires:
Path1::external_string_type
andPath2::external_string_type
are the same type.Effects: The contents and attributes of the file
from_fp
resolves to are copied to the fileto_fp
resolves to.Throws:
basic_filesystem_error<Path>
iffrom_fp.empty() || to_fp.empty() ||!exists(from_fp) || !is_regular_file(from_fp) || (option==copy_option::fail_if_exists && exists(to_fp))
template <class Path> Path complete(const Path& p, const Path& base=initial_path<Path>());
Effects: Composes a complete path from
p
andbase
, using the following rules:
p.has_root_directory()
!p.has_root_directory()
p.has_root_name()
p
precondition failure !p.has_root_name()
base.root_name()
/ pbase / p
Returns: The composed path.
Postcondition: For the returned path,
rp,
rp.is_complete()
is true.Throws: If
!(base.is_complete() && (p.is_complete() || !p.has_root_name()))
[Note: When portable behavior is required, use complete(). When operating system dependent behavior is required, use system_complete().
Portable behavior is useful when dealing with paths created internally within a program, particularly if the program should exhibit the same behavior on all operating systems.
Operating system dependent behavior is useful when dealing with paths supplied by user input, reported to program users, or when such behavior is expected by program users. -- end note]
template <class Path> Path system_complete(const Path& p);
Effects: Composes a complete path from
p
, using the same rules used by the operating system to resolve a path passed as the filename argument to standard library open functions.Returns: The composed path.
Postcondition: For the returned path,
rp,
rp.is_complete()
is true.Throws: If
p.empty()
.[Note: For POSIX,
system_complete(p)
has the same semantics ascomplete(p, current_path())
.For Windows,
system_complete(p)
has the same semantics ascomplete(ph, current_path())
ifp.is_complete() || !p.has_root_name()
orp
andbase
have the sameroot_name()
. Otherwise it acts likecomplete(p, kinky)
, wherekinky
is the current directory for thep.root_name()
drive. This will be the current directory of that drive the last time it was set, and thus may be residue left over from a prior program run by the command processor! Although these semantics are often useful, they are also very error-prone.See complete() note for usage suggestions. -- end note]
template <class Path> bool create_directories(const Path & p);
Requires:
p.empty() ||
forall px: px == p || is_parent(px, p): is_directory(px) || !exists( px )Returns: The value of
!exists(p)
prior to the establishment of the postcondition.Postcondition:
is_directory(p)
Throws:
basic_filesystem_error<Path>
ifexists(p) && !is_directory(p)
Deprecated convenience functionsThe following functions have been replaced by template <class Path> typename Path::string_type extension(const Path & p);
template <class Path> typename Path::string_type basename(const Path & p);
template <class Path> Path change_extension(const Path & p, const typename Path::string_type & new_extension);
|
<fstream>
These additions have been carefully specified to avoid breaking existing code in common operating environments such as POSIX, Windows, and OpenVMS. See Suggestions for
<fstream>
implementations for techniques to avoid breaking existing code in other environments, particularly on operating systems allowing slashes in filenames.[Note: The "do-the-right-thing" rule from Requirements on implementations does apply to header
<fstream>
.The overloads below are specified as additions rather than replacements for existing functions. This preserves existing code (perhaps using a home-grown path class) that relies on an automatic conversion to
const char*
. -- end note]
In <IP_ADDRESS> Class template basic_filebuf [lib.filebuf] synopsis preceding paragraph 1, add the function:
template <class Path> basic_filebuf<charT,traits>* open(const Path& p, ios_base::openmode mode);
In <IP_ADDRESS> Member functions [lib.filebuf.members], add the above to the signature preceding paragraph 2, and replace the sentence:
It then opens a file, if possible, whose name is the NTBS s (â€œas ifâ€ by calling
std::fopen(s ,modstr ))
.
with:
It then opens, if possible, the file that
p
orpath(s)
resolves to, â€œas ifâ€ by callingstd::fopen()
with a second argument of modstr.
In <IP_ADDRESS> Class template basic_ifstream [lib.ifstream] synopsis preceding paragraph 1, add the functions:
template <class Path> explicit basic_ifstream(const Path& p, ios_base::openmode mode = ios_base::in);
template <class Path> void open(const Path& p, ios_base::openmode mode = ios_base::in);
In <IP_ADDRESS> basic_ifstream constructors [lib.ifstream.cons] add the above constructor to the signature preceding paragraph 2, and in paragraph 2 replace
rdbuf()->open(s, mode | ios_base::in)
with
rdbuf()->open(path(s), mode | ios_base::in)
orrdbuf()->open(p, mode | ios_base::in)
as appropriate
In <IP_ADDRESS> Member functions [lib.ifstream.members] add the above open function to the signature preceding paragraph 3, and in paragraph 3 replace
rdbuf()->open(s, mode | ios_base::in)
with
rdbuf()->open(path(s), mode | ios_base::in)
orrdbuf()->open(p, mode | ios_base::in)
as appropriate
In <IP_ADDRESS> Class template basic_ofstream [lib.ofstream] synopsis preceding paragraph 1, add the functions:
template <class Path> explicit basic_ofstream(const Path& p, ios_base::openmode mode = ios_base::out);
template <class Path> void open(const Path& p, ios_base::openmode mode = ios_base::out);
In <IP_ADDRESS> basic_ofstream constructors [lib.ofstream.cons] add the above constructor to the signature preceding paragraph 2, and in paragraph 2 replace
rdbuf()->open(s, mode | ios_base::out)
with
rdbuf()->open(path(s), mode | ios_base::out)
orrdbuf()->open(p, mode | ios_base::out)
as appropriate
In <IP_ADDRESS> Member functions [lib.ofstream.members] add the above open function to the signature preceding paragraph 3, and in paragraph 3 replace
rdbuf()->open(s, mode | ios_base::out)
with
rdbuf()->open(path(s), mode | ios_base::out)
orrdbuf()->open(p, mode | ios_base::out)
as appropriate
In <IP_ADDRESS> Class template basic_fstream [lib.fstream] synopsis preceding paragraph 1, add the functions:
template <class Path> explicit basic_fstream(const Path& p, ios_base::openmode mode = ios_base::in|ios_base::out);
template <class Path> void open(const Path& p, ios_base::openmode mode = ios_base::in|ios_base::out);
In <IP_ADDRESS> basic_fstream constructors [lib.fstream.cons] add the above constructor to the signature preceding paragraph 2, and in paragraph 2 replace
rdbuf()->open(s, mode)
with
rdbuf()->open(path(s), mode)
orrdbuf()->open(p, mode)
as appropriate
In <IP_ADDRESS> Member functions [lib.fstream.members] add the above open function to the signature preceding paragraph 3, and in paragraph 3 replace
rdbuf()->open(s, mode)
with
rdbuf()->open(path(s), mode)
orrdbuf()->open(p, mode)
as appropriate
End of proposed text.
The table is generated by a program compiled with the Boost implementation.
Shaded entries indicate cases where POSIX and Windows
implementations yield different results. The top value is the
POSIX result and the bottom value is the Windows result.
| Constructor argument |
Elements found by iteration |
string() |
file_ |
root_ |
root_ |
root_ |
relative_ |
parent_ |
filename() |
"" |
"" |
"" |
"" |
"" |
"" |
"" |
"" |
"" |
"" |
"." |
"." |
"." |
"." |
"" |
"" |
"" |
"." |
"" |
"." |
".." |
".." |
".." |
".." |
"" |
"" |
"" |
".." |
"" |
".." |
"foo" |
"foo" |
"foo" |
"foo" |
"" |
"" |
"" |
"foo" |
"" |
"foo" |
"/" |
"/" |
"/" |
"/" |
"/" |
"" |
"/" |
"" |
"" |
"/" |
"/foo" |
"/","foo" |
"/foo" |
"/foo" |
"/" |
"" |
"/" |
"foo" |
"/" |
"foo" |
"foo/" |
"foo","." |
"foo/" |
"foo/" |
"" |
"" |
"" |
"foo/" |
"foo" |
"." |
"/foo/" |
"/","foo","." |
"/foo/" |
"/foo/" |
"/" |
"" |
"/" |
"foo/" |
"/foo" |
"." |
"foo/bar" |
"foo","bar" |
"foo/bar" |
"foo/bar" |
"" |
"" |
"" |
"foo/bar" |
"foo" |
"bar" |
"/foo/bar" |
"/","foo","bar" |
"/foo/bar" |
"/foo/bar" |
"/" |
"" |
"/" |
"foo/bar" |
"/foo" |
"bar" |
"///foo///" |
"/","foo","." |
"///foo///" |
"///foo///" |
"/" |
"" |
"/" |
"foo///" |
"///foo" |
"." |
"///foo///bar" |
"/","foo","bar" |
"///foo///bar" |
"///foo///bar" |
"/" |
"" |
"/" |
"foo///bar" |
"///foo" |
"bar" |
"/." |
"/","." |
"/." |
"/." |
"/" |
"" |
"/" |
"." |
"/" |
"." |
"./" |
".","." |
"./" |
"./" |
"" |
"" |
"" |
"./" |
"." |
"." |
"/.." |
"/",".." |
"/.." |
"/.." |
"/" |
"" |
"/" |
".." |
"/" |
".." |
"../" |
"..","." |
"../" |
"../" |
"" |
"" |
"" |
"../" |
".." |
"." |
"foo/." |
"foo","." |
"foo/." |
"foo/." |
"" |
"" |
"" |
"foo/." |
"foo" |
"." |
"foo/.." |
"foo",".." |
"foo/.." |
"foo/.." |
"" |
"" |
"" |
"foo/.." |
"foo" |
".." |
"foo/./" |
"foo",".","." |
"foo/./" |
"foo/./" |
"" |
"" |
"" |
"foo/./" |
"foo/." |
"." |
"foo/./bar" |
"foo",".","bar" |
"foo/./bar" |
"foo/./bar" |
"" |
"" |
"" |
"foo/./bar" |
"foo/." |
"bar" |
"foo/.." |
"foo",".." |
"foo/.." |
"foo/.." |
"" |
"" |
"" |
"foo/.." |
"foo" |
".." |
"foo/../" |
"foo","..","." |
"foo/../" |
"foo/../" |
"" |
"" |
"" |
"foo/../" |
"foo/.." |
"." |
"foo/../bar" |
"foo","..","bar" |
"foo/../bar" |
"foo/../bar" |
"" |
"" |
"" |
"foo/../bar" |
"foo/.." |
"bar" |
"c:" |
"c:" |
"c:" |
"c:" |
"" |
"" |
"" |
"c:" |
"" |
"c:" |
"c:/" |
"c:","." |
"c:/" |
"c:/" |
"" |
"" |
"" |
"c:/" |
"c:" |
"." |
"c:foo" |
"c:foo" |
"c:foo" |
"c:foo" |
"" |
"" |
"" |
"c:foo" |
"" |
"c:foo" |
"c:/foo" |
"c:","foo" |
"c:/foo" |
"c:/foo" |
"" |
"" |
"" |
"c:/foo" |
"c:" |
"foo" |
"c:foo/" |
"c:foo","." |
"c:foo/" |
"c:foo/" |
"" |
"" |
"" |
"c:foo/" |
"c:foo" |
"." |
"c:/foo/" |
"c:","foo","." |
"c:/foo/" |
"c:/foo/" |
"" |
"" |
"" |
"c:/foo/" |
"c:/foo" |
"." |
"c:/foo/bar" |
"c:","foo","bar" |
"c:/foo/bar" |
"c:/foo/bar" |
"" |
"" |
"" |
"c:/foo/bar" |
"c:/foo" |
"bar" |
"prn:" |
"prn:" |
"prn:" |
"prn:" |
"" |
"" |
"" |
"prn:" |
"" |
"prn:" |
"c:\" |
"c:\" |
"c:\" |
"c:\" |
"" |
"" |
"" |
"c:\" |
"" |
"c:\" |
"c:foo" |
"c:foo" |
"c:foo" |
"c:foo" |
"" |
"" |
"" |
"c:foo" |
"" |
"c:foo" |
"c:\foo" |
"c:\foo" |
"c:\foo" |
"c:\foo" |
"" |
"" |
"" |
"c:\foo" |
"" |
"c:\foo" |
"c:foo\" |
"c:foo\" |
"c:foo\" |
"c:foo\" |
"" |
"" |
"" |
"c:foo\" |
"" |
"c:foo\" |
"c:\foo\" |
"c:\foo\" |
"c:\foo\" |
"c:\foo\" |
"" |
"" |
"" |
"c:\foo\" |
"" |
"c:\foo\" |
"c:\foo/" |
"c:\foo","." |
"c:\foo/" |
"c:\foo/" |
"" |
"" |
"" |
"c:\foo/" |
"c:\foo" |
"." |
"c:/foo\bar" |
"c:","foo\bar" |
"c:/foo\bar" |
"c:/foo\bar" |
"" |
"" |
"" |
"c:/foo\bar" |
"c:" |
"foo\bar" |
<fstream>
implementationsThe change in semantics to functions
taking const char*
arguments can break existing code, but only on
operating systems where implementations don't
implicitly accept native format pathnames or
operating systems that allow slashes in filenames. Thus on POSIX,
Windows, and OpenVMS, for example, there is no problem if the
implementation follows encouraged behavior.
For most of the Filesystem Library,
there is no existing code, so the issue preserving existing code that uses
slashes in filenames doesn't arise. New code simply must use basic_path
constructors with path_format_t
arguments of native
.
To preserve existing fstream code that uses slashes in filenames, an
implementation may wish to provide a mechanism such as a macro to control
selection of the old behavior.
Implementations are already required
by the TR front-matter to provide a mechanism such as a macro to control
selection of the old behavior (useful to guarantee protection of existing code)
or new behavior (useful in new code, and code being ported from other systems)
for headers. Because use of the rest of the Filesystem Library is independent of
use of the <fstream>
additions, affected implementations are
encouraged to allow disabling the <fstream>
additions separately
from other TR features.
An rejected alternative was to supply
new fstream classes in namespace filesystem
, inheriting from the current
classes, overriding the constructors and opens taking pathname arguments, and
providing the additional overloads. In Lillehammer LWG members indicated lack of
support for this alternative, feeling that costs outweigh benefits.
This Filesystem Library is dedicated to my wife, Sonda, who provided the support necessary to see both a trial implementation and the proposal itself through to completion. She gave me the strength to continue after a difficult year of cancer treatment in the middle of it all.
Many people contributed technical comments, ideas, and suggestions to the Boost Filesystem Library. See http://www.boost.org/libs/filesystem/doc/index.htm#Acknowledgements.
Dietmar Kuehl contributed the original Boost Filesystem Library directory_iterator design. Peter Dimov, Walter Landry, Rob Stewart, and Thomas Witt were particularly helpful in refining the library.
The create_directories, extension, basename, and replace_extension functions were developed by Vladimir Prus.
Howard Hinnant and John Maddock reviewed a draft of the proposal, and identified a number of mistakes or weaknesses, resulting in a more polished final document.
| [ISO-POSIX] | ISO/IEC 9945:2003, IEEE Std 1003.1-2001, and The Open Group Base Specifications, Issue 6. Also known as The Single UnixÂ® Specification, Version 3. Available from each of the organizations involved in its creation. For example, read online or download from www.unix.org/single_unix_specification/. The ISO JTC1/SC22/WG15 - POSIX homepage is www.open-std.org/jtc1/sc22/WG15/ |
| [Abrahams] | Dave Abrahams, Error and Exception Handling, www.boost.org/more/error_handling.html |
© Copyright Beman Dawes, 2002, 2006, 2007
Distributed under the Boost Software License, Version 1.0. See www.boost.org/LICENSE_1_0.txt
Revised 10 November 2009


| 1 | package fr.sii.ogham.core.util; | |
| 2 | ||
| 3 | import java.util.function.Predicate; | |
| 4 | ||
| 5 | import fr.sii.ogham.core.message.content.Content; | |
| 6 | ||
| 7 | /** | |
| 8 | * Entry that declares a handler that is capable of handling a particular | |
| 9 | * content if the provided matcher matches the content. | |
| 10 | * | |
| 11 | * The entry has also a priority order. Several handlers may be registered and | |
| 12 | * able to handle a particular content. Only the one with the highest priority | |
| 13 | * is used. | |
| 14 | * | |
| 15 | * @author Aurélien Baudet | |
| 16 | * | |
| 17 | * @param <T> | |
| 18 | * the handler type | |
| 19 | */ | |
| 20 | public class PriorizedMatchingHandler<T> { | |
| 21 | /** | |
| 22 | * The matcher used to check if the content can be handled by the associated | |
| 23 | * handler | |
| 24 | */ | |
| 25 | private final Predicate<Content> contentMatcher; | |
| 26 | /** | |
| 27 | * The handler | |
| 28 | */ | |
| 29 | private final T handler; | |
| 30 | /** | |
| 31 | * The priority of the handler | |
| 32 | */ | |
| 33 | private final int priority; | |
| 34 | ||
| 35 | public PriorizedMatchingHandler(Predicate<Content> contentMatcher, T handler, int priority) { | |
| 36 | super(); | |
| 37 | this.contentMatcher = contentMatcher; | |
| 38 | this.handler = handler; | |
| 39 | this.priority = priority; | |
| 40 | } | |
| 41 | ||
| 42 | public boolean matches(Content content) { | |
| 43 |
2
1. matches : replaced boolean return with true for fr/sii/ogham/core/util/PriorizedMatchingHandler::matches → NO_COVERAGE 2. matches : replaced boolean return with false for fr/sii/ogham/core/util/PriorizedMatchingHandler::matches → NO_COVERAGE |
return contentMatcher.test(content); |
| 44 | } | |
| 45 | ||
| 46 | public T getHandler() { | |
| 47 |
1
1. getHandler : replaced return value with null for fr/sii/ogham/core/util/PriorizedMatchingHandler::getHandler → NO_COVERAGE |
return handler; |
| 48 | } | |
| 49 | ||
| 50 | public int getPriority() { | |
| 51 |
1
1. getPriority : replaced int return with 0 for fr/sii/ogham/core/util/PriorizedMatchingHandler::getPriority → NO_COVERAGE |
return priority; |
| 52 | } | |
| 53 | } | |
Mutations | ||
| 43 |
1.1 2.2 |
|
| 47 |
1.1 |
|
| 51 |
1.1 |


{{device_name}}
Set up Coder's Wifi
Enter your network name and password so Coder can connect and you can get started.
Select Wifi Network
Rescan for Available Networks
--------------------------------
Wifi Password
Save Wifi Settings and Reboot
Cancel
Switch Your Wireless
Unplug Coder's ethernet cable and connect your computer to your normal wireless network. Your Coder will take a minute to restart.
If your Coder fails to connect to the wireless network, it will reconnect to the CoderConfig network.
Reconnect to coder.local


| Sr | Fieldname | Type | Label | Options |
|---|---|---|---|---|
| 1 | actions_sb |
Section Break | Actions | |
| 2 | actions |
Table | Actions | Setup Progress Action |
Inherits from frappe.model.document.Document
erpnext.setup.doctype.setup_progress.setup_progress.get_action_completed_state (action_name)
No docs
erpnext.setup.doctype.setup_progress.setup_progress.get_domain_actions_state (domain)
No docs
erpnext.setup.doctype.setup_progress.setup_progress.get_setup_progress ()
No docs
Public API
/api/method/erpnext.setup.doctype.setup_progress.setup_progress.set_action_completed_state
erpnext.setup.doctype.setup_progress.setup_progress.set_action_completed_state (action_name)
No docs
erpnext.setup.doctype.setup_progress.setup_progress.update_action (doc)
No docs
erpnext.setup.doctype.setup_progress.setup_progress.update_action_completed_state (action_name)
No docs
erpnext.setup.doctype.setup_progress.setup_progress.update_domain_actions (domain)
No docs


?7
8
9
10
The
New
York
copyright
reserved
botanical
Garden
New
York
Botanical
Garden
lb2S511
EX
HERB.
HORT.
BOT.
REG.
KEW.
f
T.
C
/?/¥_£
FLORA
OF
TRINIDAD
eLJt_
.
Leaves
up
to
at
least
130
cm.
long,
45
cm.
wide,
nerves
prominent
above
&
beneath.
Bane
of
lamina
truncate
to
cuneate.
Spathe
very
pale
green
rapidly
becoming
striated
with
purple
until
totally
dull
purple.
Spadix
blackish
purple,
anthers
orange.
Developing
(wJb
faint
white
when
young,
through
pink
to
pale
mauve-purple.
Terrestrial
on
wooded
rockv
*1
¥
MvOV4r
È
slope
overlooking
Telagsiffa
Bay.
Many
plants.
Point
Gourde.
D.Philcox
28
July
1977
1622511
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


It's very easy to navigate between the Django templates and referencing views.
To do that, use the icons and in the left gutter of the editor.


In many cultures, eyes are very special. As we can see, the element of eyes runs through the whole article in the spectacular novel Ghost Blows the Lamp.
When I flicked through website of Douban at the weekend, I found Higashino Keigo’s novel named Dying Eye, which only with a score of 6.4. For me, such low evaluation would not made me to read the book, while the poster caught my attention.
The hero is a bartender and the plot of the story begins with an accident in a rainy night. The hero hit a pedestrian who was riding a bicycle, and caused her death.
A year later, he was attacked by a guest after work. When he regained consciousness, he found that some important memories had disappeared. In search of memory, a mysterious woman approached to him by some reason. WHO IS SHE?
It took me about three hours to finish reading the novel, and the whole story was very fluid and a little weird. I don’t understand why the score is so low, and I think it is worth reading.
In addition, the Japanese drama that adapted from the novel is being serialized. I will write a film review after watching it :D
「中文部分」
在很多文化环境下，「眼睛」都是很特别的一种存在。比如说天下霸唱写的《鬼吹灯》，可以说眼睛这个元素贯穿了文章始终。周末在豆瓣上浏览，我发现了东野圭吾的《濒死之眼》，分数仅有6.4分。这么低的分数照理来说不会让我去打开阅读，但是海报却吸引住了我。
故事的情节是随着雨夜的一场车祸展开的，男主角开车撞死了一位骑着自行车的行人，导致对方当场死亡。一年半过去，他在下班后被人袭击，恢复意识后发现一部分重要记忆消失了。在找寻记忆的同时，身边出现了一名接近他的神秘女性，这个人是谁呢？
我大概花了三个半小时阅读完了这部小说，整个故事非常流畅并有一些诡异。不理解为什么评分会如此之低，个人感觉还是非常值得阅读的。
另外，由小说改编的日剧正在更新中，等看完了我会写一篇影评:D
豆瓣评分：6.4
本文首发于Steemit。谢谢大家的来看我的文章，如果您喜欢的话，请转发、留言或是点赞。你们的支持是我继续努力的最大动力，再次感谢～
Thank you for reading my articles. If you like me, plz forward, upvote me or leave your comments. Thx a looooooot~
This page is synchronized from the post: ‘Book Review「濒死之眼 ダイイング・アイ / Dying Eye」20190423’


A user-friendly app that facilitates the search for majors, colleges, jobs, and references.
Degreebee helps students explore various majors, allowing them to find jobs related to a major, discover colleges that offer the major, and connect with those who have experience or expertise in that major.
This first screen shows general categories that users can click to discover majors under their category of interest.
This list includes all majors under the category clicked by the user.
The search function allows users who already have an idea of a major to directly find their major of interest.
This page offers detailed information about the major. There are short lists of the jobs related to the major, colleges that offer the major, and references who have experience with the major. As the user scrolls up, the toolbar collapses. Users can also share/save the major if they are interested in it.
This is an example of the expanded list of colleges when the user clicks "Show All." The jobs and references lists follow a similar format.
References can be added dynamically to the database, and one only has to enter his/her name and email.
Email<EMAIL_ADDRESS>Friend me on Facebook!
Follow me on Quora!
Check out my Github!
Connect with me on Linkedin!
Please contact me for any reason and feel free to give feedback as well!


Last Updated: March 31 3:31pm (MST)
Covid-19
Data
Team
About
THE COVID-19 RESPONSE
How is Alberta doing and what should we be doing next?


Students form human chain ahead of HRD ministry-appointed panel's visit to JNU
The panel members entered the university from another gate as students had formed a human chain inside the varsity campus to demand complete rollback of fee hike.
Jawaharlal Nehru University (JNU) students on Friday formed a human chain inside the university campus to demand complete rollback of fee hike, ahead of a visit of the Ministry of Human Resource Development-appointed high-powered committee to the varsity to meet students' union representatives.
Former students' union president N Sai Balaji said, "Students are standing here to welcome the high-powered committee. The students want to tell them about the issues arising due to fee hike."
PANEL REACHES JNU TO HOLD TALKS WITH STUDENTS
The panel reached the JNU campus on Friday to hold talks with the students regarding their disputes with the administration on the hostel fee hike issue.
The panel members entered the university from another gate as students had formed a human chain inside the varsity campus to demand complete rollback of fee hike, ahead of the visit.
The HRD ministry had formed the three-member committee on Monday to recommend ways to restore normal functioning of the Jawaharlal Nehru University and mediate between the administration and students who have been protesting for over three weeks over the hostel fee hike.
The first meeting of the panel with JNU Students Union (JNUSU) office-bearers, student counsellors and hostel presidents took place on Wednesday at Ministry of Human Resource Development.
The panel has also met JNU Teachers Association (JNUTA) members and deans of all schools.


WITNESS LIST Infrastructure Development and Security Committee May 15, 2003 - 9:00A HB 2006 FOR: Allen, Albert N. Real Estate Appraiser (Texas Oil & Gas Association), Addicks, TX Harwell, Tom Community Outreach - Public Awareness (Koch Pipeline Company, LP), Wichita, KS Mann, James Lawyer (Texas Pipeline Association), Austin, TX Patterson, Joseph Attorney - Eminent Domain (Texas Oil & Gas Association), Angleton, TX Wurtz, Alan D. Regional Right of Way Manager (Enterprise), Houston, TX AGAINST: Aadnesen, Christopher Transportation Advisor (The Texas Mexican Railway Company), Georgetown, TX Alcorta, Victor Attorney (Railroad Management Company), Austin, TX Bilderback, Blaine Director Development & Acquisition (Burlington Northern Santa Fe Railroad), Ft. Worth, TX Hegi, Alan Attorney (The Burlington Northern and Santa Fe Railway Co.), Ft. Worth, TX Newman, Cary Property Management (Railroad Management Company), Dallas, TX Smith, Christine Attorney (Union Pacific Railroad Company), Omaha, NE Registering, but not testifying: For: Allday, Marty (COPANO Energy), Houston, TX Camacho, Jose A. Lobbyist (UALON Telecom), Austin, TX Fainter, John Lobbyist (Association of Electric Companies of Texas), Austin, TX Fitzgerald, Amy Staff Counsel (Texas Electric Cooperatives), Austin, TX Flores, Henry Director - Government Affairs (Sprint Corporation), Austin, TX Grover, Jim Director Governmental Affairs (Texas Telephone Association), Austin, TX Grundman, Rick (Texas Gas Service Company), Austin, TX Hughes, Cammie Telecommunications (Texas Statewide Telephone Company), Austin, TX Mayberry, Warren E. Director Legislative Affairs (Texas Farm Bureau), Austin, TX Moore, Julie W. Director (Occidental Petroleum), Austin, TX Nugent, Patrick Executive Director (Texas Pipeline Association), Austin, TX Olson, Kym Government Affairs (El Paso Corporation), Houston, TX Oswald, Bill Director - Government Relations Affairs (Koch Industries, Flint Hills Resources, Gulf South Pipeline), Austin, TX Patton, Charles VP - Government Affairs (Houston Pipeline Company), Austin, TX Perry, Steve Government Relations (Chevron Texaco), Austin, TX Reinhart, Patrick W. Director - External Affairs (SBC), Austin, TX Sander, Lindsay Government Affairs (Enbridge Energy Company, Inc.), Houston, TX Sebree, Ben Association Manager (Texas Oil & Gas Association), Austin, TX Sellers, Tom Manager of State Government Affairs (Conoco Phillips), Austin, TX Stevens, Bill Executive Vice President (Texas Alliance of Energy Producers), Abilene, TX Talavera, Judith Manager, Government Affairs (American Electric Power), Austin, TX Tays, Sara PA Manager (Exxon Mobil Corporation), Austin, TX Turner, Bob Consultant (Texas Sheep & Goat Raisers Association), Austin, TX Woodard, Shayne Lobbyist (Duke Energy), Austin, TX Woodard, Shayne Lobbyist (Sunoco, Inc.), Austin, TX Against: Arterburn, David Assistant Legislative Director (United Transportation Union), Austin, TX Calhoun, Frank W. Attorney at Law (BNSF Railway), Austin, TX Cates, Phil Texas Stakeholders (RSI), Austin, TX Dixon, Mark Vice President - Engineering & Safety (Georgetown RR Co.), Austin, TX Eyermann, David Vice President (Dallas, Garland & Northeastern Railroad), Richardson, TX Eyermann, David Vice President (Kiamichi Railroad), Richardson, TX Eyermann, David Vice President (Texas Northeastern Railroad), Richardson, TX Eyermann, David President (Texas Shortline & Regional Railroad Association), Richardson, TX Garcia, Victor L. Manager of Safety and Security (The Texas Mexican Railway Co.), Laredo, TX Kearns, Dennis Attorney (Burlington Northern Santa Fe Railway), Austin, TX Olson, Ron Special Rep. (Union Pacific RR), Austin, TX Pinker, Greg L. Director - Contracts (Union Pacific Railroad Company), Omaha, NE Rankin, David Attorney (Burlington Northern Santa Fe), Ft. Worth, TX Roberson, Robert C. Chairman CEO (Ft. Worth & Western Railroad), Ft. Worth, TX Watkins, Joe Bill Attorney/Lobbyist (Kansas City Southern Railway), Austin, TX On: Barton, Bill Attorney (Texas Railroad Association), Austin, TX HB 3184 ON: Jackson, Bob Deputy General Counsel (Texas Department of Transportation), Austin, TX Nichols, Robert Member (Texas Transportation Commission), Austin, TX Stagner, Steve (Texas Council of Engineering Companies), Austin, TX Registering, but not testifying: On: Polumbo, Carol Attorney (Texas Department of Transportatioi), Austin, TX Providing written testimony: On: Sullivan, Ray Sullivan Public Affairs (UBS Paine Webber), Austin, TX


There are currently no specific recommendations for the amount of children and young people’s sport or dance participation. However, in line with Sport Wales’ Vision of ‘Every Child Hooked on Sport for Life’, the percentage of children ‘hooked on sport’ was used by the Research Work Group as the benchmark for grading this indicator.
In the Active Healthy Kids Wales 2016 Report Card, the percentage of children ‘hooked on sport’ (in line with Sport Wales’ Vision of ‘Every Child Hooked on Sport for Life’) was used by the Research Work Group as the benchmark for grading this indicator. However, due to changes from a 2-year cycle to a 3-year cycle in the administration of the Sport Wales’ School Sport Survey, up to date data on children and young people ‘hooked on sport’ was not available.
The Research Work Group therefore decided to use the Active Health Kids Global Alliance benchmark to allow for the best available data to be included in the grading of this indicator.
For children ages 7-16 years old
The percentage of children who take part in sport on three or
more occasions a week, in an extracurricular (school-based) or a
community club setting. Curricular PE activity is not included.
For young people aged 16+ years old
The percentage of young people who take part in sport on three
or more occasions a week, in any setting.
A nationally representative data source was used by the Research Work Group to assign an organised sport participation grade.
The School Health Research Network: Student Health and Wellbeing
Survey (2017) collected self-report data on 112,054 children and young
people aged 11-17 years old. Distributed to 193 schools in Wales,
children and young people were asked to report organised activities
they took part in, in their free time outside of school. Possible
responses to this question were as follows:
a) Organised team sport activities (e.g. football, basketball and
volleyball)
b) Organised individual sport activities (e.g.
tennis, gymnastics and karate)
c) Attending drama, arts or music
groups (e.g. orchestra, choir, dance, theatre, playing a musical
instrument)
d) Attending a club (e.g. chess club, debate club,
science club)
e) Children and youth organisations (e.g.
scouting, guides, cadets, Duke of Edinburgh)
f) Attending
faith-based activities (religious services, classes and religious
youth groups)
g) Volunteering for a club or organisation
The Research Work Group decided that responses, a) Organised team sport activities (e.g. football, basketball and volleyball), b) Organised individual sport activities (e.g. tennis, gymnastics and karate) and e) Children and youth organisations (e.g. scouting, guides, cadets, Duke of Edinburgh) should be considered for grading this indicator. The justification for the inclusion of ‘children and youth organisations’ was that these organisations promote physical activity through outdoor physical activities and adventures. (The research work group considered using response c) to include dance, but due to dance being pooled with other art forms this response was excluded)
The survey showed that 55% of children and young people reported attending at least one of these outside school organised activities. There was a difference in the proportion of boys and girls attending at least one of these outside school organised activities (60% boys and 51% girls). There was also a difference in the proportion of children and young people across ethnicities; 56% among white populations and 47% among black and minority ethnic (BME) populations, reported attending atleast one of these outside school organised activities.
The School Sport Survey (2015) provides data on 115,398 children aged 7-16 years old from across Wales. The survey showed that 48% of children were ‘hooked on sport’ (children who take part in sport on three or more occasions a week in an extracurricular or community club setting). These data showed an upward trend in the percentage of children ‘hooked on sport’ from 27, 40, and 48 percent in 2011, 2013 and 2015, respectively. Moreover, similar proportions of primary (49%) and secondary (48%) age school children were ‘hooked on sport’, although more boys (52%) were ‘hooked on sport’ than girls (44%). Even though there were differences by age, ethnicity, disability and socioeconomic status, there has been an overall increase in the proportion of children ‘hooked on sport’ between 2013 and 2015 for both boys and girls across all of these subgroups (age, ethnicity, disability and socioeconomic status).
The Further Education Sport Survey (2015) collected data on 4,568 students aged 16+ years old from 12 FE colleges across Wales. The survey showed that 49% of students were ‘hooked on sport’ (take part in sport on three or more occasions a week, in any setting). Specifically in the younger students aged 16-19 years old, 52% of these students were ‘hooked on sport’. The findings in relation to subgroups (gender, age, ethnicity, disability and socioeconomic status) in this survey were very similar to findings from the School Sport Survey (2015). However, trends could not be established due to the survey data being in the first year of data collection.