There are a number of differences. Some were, I believe, Boost changes that were never propagated. For example, there is no path.filename_is_dot() query (as discussed below, it would be less useful in std::filesystem anyway).
There was also a good bit of late-breaking news on this front:
- Support for non-POSIX-like filesystems:
- Specify whether a string is OS-native or POSIX-like (or let the implementation decide, which is (still) the default)
- An implementation may define additional file types (beyond regular, directory, socket, etc.)
- An implementation may define
file_sizefor a directory or device file
filename(), normalization, and relative/absolute conversions redefined (examples for POSIX):path("foo/.").lexically_normal()=="foo/"(is the opposite in Boost)path("foo/").filename()==""(ispath(".")in Boost)remove_filename()leaves the trailing slash and is thus idempotent (it assignsparent_path()in Boost)path(".profile").extension()==""(is the whole name in Boost)pathdecompositions and combinations can preserve things like alternate data stream names that are normally invisiblepath("foo")/"/bar"=="/bar"(ispath("foo/bar")in Boost), which allows composing relative file names with others (absolute or relative) and replaces Boost’sabsolute()- Boost’s
system_complete()(which takes only one argument) is renamed toabsolute() canonical()thus takes only one argument (fixed in a DR)lexically_relative()handles..and root elements correctlypermissions()takes more arguments (Boost combines them into a bitmask)
Note that Boost.Filesystem v4 is under development and is supposed to be C++17-compatible (but therefore incompatible in many respects with v3).