v4 remove_filename works similar to std::filesystem, i.e. preserves
the trailing directory separator after removing the filename.
v3 remove_filename works as before. Its behavior is also useful in
v4, so added a new method remove_filename_and_trailing_separators
with the same behavior.
Also added replace_filename that was previously missing.
remove_filename discrepancy from std::filesystem was reported in:
https://github.com/boostorg/filesystem/issues/271
This causes ambiguities in users' code where the previously added conversion
from user-defined types that have a conversion to one of the path source
types:
struct my_class
{
operator std::string() const;
};
std::string to_string(std::string const&);
std::string to_string(boost::filesystem::path const&);
to_string(my_class());
The above call is ambiguous as the conversion operator in my_class and
a converting constructor in boost::filesystem::path from my_class are
both available and have equivalent ranks.
Removing the conversion constructors from boost::filesystem::path
means users will have to explicitly cast their types to one of the
path source types before constructing path.
In order to preserve backward compatibility with operator== and operator!=
for paths that also accepted source types (path::string_type,
const path::value_type*), we have to update path::compare and comparison
operators to accept types that are convertible to source types.
Fixes https://github.com/boostorg/filesystem/issues/273.
Path traits and relevant path members were reworked to better support
wider range of types that are compatible with path constructors, assignment
and appending members. Added support for C++17 std::string_view,
boost::string_view and boost::container::string as the possible string
types accepted by path members.
Also extended support for types convertible to one of the string types.
Previously, user's type had to be convertible to a string with a character
type that matches the native path character type. Now all supported character
types are acceptable.
Additionally, restricted members accepting a pair of iterators to only accept
iterators whose value types are one of the supported path character types.
Lastly, path::compare and comparison operators now only accept path arguments,
relying on path conversion constructors to do the job of supporting various
source types. Also removed noexcept from compare as it is using lex_compare
and iterators internally and those can throw.
Closes https://github.com/boostorg/filesystem/issues/208.
In v4 path::lexically_normal, don't generate a trailing dot element if the
original path ends with a directory separator or dot. Also omit the trailing
directory separator the normalized path ends with a dot-dot element.
Additionally, convert directory separators to preferred separators in
root name on Windows (in v3 and v4). This may be significant for UNC paths.
If the source path ends with a non-empty filename, and the appended path
is empty, C++17 std::filesystem requires to add a trailing directory
separator.
Appending an absolute path now results in assigning the path, as
specified in C++17. This change is made for consistency with C++
and other languages that implement path manipulation (e.g. Python).
In Boost.Filesystem v3 path appending mostly worked as a slight upgrade
of concatenation, where appending would only add directory separators
when necessary, but not consider semantics of the root name and root
directory of the appended paths. This would work well for relative paths,
but produce unexpected results for paths with root names.
In v4, we now implement appending that is aware of root name and directory
of the appendedn paths. This means that appending a path with a root name
and/or directory no longer concatenates the paths, but rather rebases the
appended path on top of the source path. In particular, if the appended path
has a root name different from the source path, the append operation will
act as assignment.
This is closer to C++20 std::filesystem but not exactly the same. The
difference is for the case when the appended path is absolute. The C++20
spec requires assignment in this case, Boost.Filesystem v4 deliberately
omits this check. This is to ensure the correct result for UNC paths on
POSIX systems, where "//net/foo" / "/bar" is expected to produce "//net/bar",
not "/bar".
As part of this work, refactored path constructors and operators for more
optimal implementation and reducing the number of overloads.
Closes https://github.com/boostorg/filesystem/issues/214.
When the path ends with a non-root directory separator, no longer
produce a trailing dot element (filename). Instead, return an empty
path.
This affects not only path iterators and path::filename, but also any
other APIs that rely on them.
Closes https://github.com/boostorg/filesystem/issues/193.
Boost.Filesystem v4 will contain breaking changes from v3 that are required
for better compatibility with C++17 std::filesystem. It will also remove
the deprecated features of v3.
Updated docs to reflect the differences between v3 and v4. Updated tests
to verify both v3 and v4 where the differences are present.
This is a breaking change.
path::filename accessor now only returns the actual filename or the implied
trailing dot element of the path, if it ends with a separator other than
root directory. This makes boost::filesystem::path behavior closer to that
of std::filesystem::path.
Updated tests and docs accordingly.
Closes https://github.com/boostorg/filesystem/issues/194.
Filenames starting with a dot (and no other dots) are commonly treated
as filenames with no extension rather than an extension. This is also
the behavior mandated in C++17 filesystem.
Reported in https://github.com/boostorg/filesystem/issues/88.
The new implementation is also not relying on the root name format and
is more pertormant as it avoids unnecessarily copying path elements during
operation.
Note that this commit does not remove the trailing dot elements in the
normalized paths.
- Unified root name and root directory parsing that was scattered and
duplicated across different algorithms. The new implementation is
consolidated in a single function for parsing root name and root
directory, which is used from various algorithms.
- The new root name parsing now supports Windows local device ("\\.\")
and NT path ("\??\") prefixes. It also adds support for filesystem
("\\?\") prefix to some of the higher level algorithms that were
using custom parsing previously. Tests updated to verify these prefixes.
- Some of the path decomposition methods were unified with presence checking
methods (e.g. root_name with has_root_name). This makes these methods
work consistently and also makes the has_* methods less expensive as
they no longer have to construct a path only to check if it is empty.
- The filename accessor no longer returns root name if the whole path
only consists of a root name. This also affects stem and extension as
those accessors are based on filename. This is a breaking change.
- Cleaned up code:
- Removed redundant checks for std::wstring support.
- Added header/footer headers to globally disable compiler warnings.
- Removed commented out super-deprecated code.
- Added missing includes and removed includes that are not needed.
- Nonessential code formatting.
Directory iteration components were moved to separate files to simplify
maintenance of operations.hpp/cpp.
directory_iterator implementation on POSIX platforms has been reworked
to only allocate internal buffer when readdir_r is used. When readdir
is used, the dirent structure returned by readdir is used directly, which
eliminates the potential of buffer overrun in case if some directory name
exceeds the buffer size. This also removes the need to copy dirent members
into the buffer, which improves performance and simplifies maintenance.
For buffer size we now use the max path size as opposed to max filename
size. This is done to minimize the possibility of buffer overruns when
readdir_r is used.
On Windows, use Boost.WinAPI to configure the default target Windows version.
This removes WINVER and _WIN32_WINNT defines in Boost.Filesystem as these
macros should be defined by Boost.WinAPI now.
Additionally, exception.hpp and directory.hpp includes in operations.hpp are
marked as deprecated as operations.hpp do not need those components. Users
are encouraged to include the new headers explicitly in their code, as needed.
When using Boost.Filesystem from a project compiled as C++/CX code,
compilation fails with a syntax error, because generic is a keyword.
error C2059: syntax error: 'generic'
See section "Generic interfaces" in C++/CX here:
https://msdn.microsoft.com/en-us/library/hh755792.aspx
