CODEWITHSUNDEEP
c++c++14c++17
user79878
user79878

Reputation: 845

Differences between c++14 std::experimental::filesystem::v1 and c++17 std::filesystem?

I found this page, describing the changes between c++14 and c++17:

https://isocpp.org/files/papers/p0636r0.html

... It links to this page, which describes the proposed filesystem changes:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0218r0.html

I skimmed through it. There are small wording changes to the standard, but the only code change I saw were namespace changes that removed the "experimental" and "v1" parts, so "std::experimental::filesystem::v1" became "std::filesystem", which is expected.

From what I can tell, nothing other than the namespace path changed. Does anyone know if anything else changed?

In other words, I'm using gcc with -std=c++14. Can I write code now with std::experimental::filesystem and comfortably switch to -std=c++17 in the future with only this namespace change?

Closest questions I can find to being duplicates:

How similar are Boost filesystem and the standard C++ filesystem libraries?

Are the experimental features of modern C++ reliable for long-term projects?

Upvotes: 11

Views: 11883

Answers (2)

Venkatesh MC
Venkatesh MC

Reputation: 400

A delayed reply, but I came across this question when I was myself looking for the answer to the same question. When I finally figured things out, I thought I'd post my observations here.

When migrating from std::experimental::filesystem to std::filesystem, I came across the following changes:

std::experimental::filesystem std::filesystem (C++17)
canonical() has an overload which accepts a base path, which could be used to resolve the path passed in the first argument canonical() doesn't have this overload, and that broke some of my code
canonical() doesn't check for the existence of the path canonical() does check for the existence of the path, so if you have situations where the path may not exist at the time of calling this function, switch to std::filesystem::weakly_canonical
The insertion operator (<<) gives you the string as it is, unquoted and unescaped. E.g. C:\my\file.txt The insertion operator (<<) adds quotes around the full path and escapes the backslashes (\). E.g. "C:\\my\\file.txt" This broke some of my tests and I had to call the string (or the wstring) methods of the path object to get the unquoted and unescaped string.
file_time_type is a typedef of std::chrono::system_clock::time_point file_time_type is an alias of std::chrono::time_point<filesystem::_File_time_clock>. This caused compilation errors at some places in my code where I was expecting it to be a system_clock::time_point.

Upvotes: 5

T.C.
T.C.

Reputation: 137404

The major papers making changes to the filesystem library are

  • P0219R1, adding relative paths support
  • P0317R1, adding caching to directory_entry
  • P0492R2, a lengthy list of fixes and changes in response to national body comments
  • P0430R2, support for certain non-POSIX systems

There are also some relatively minor fixes and changes that can be found in the LWG issue list. Look for issues with "C++17" status. Note that some of these changes are then superseded by the papers listed above.

For existing Filesystem TS code, I expect that P0492R2 is the one that matters the most, since the remaining papers are mostly feature additions rather than changes. P0492R2 includes both technical clarifications and significant semantic changes. Some in the latter category that immediately come to mind are:

  • path(".profile").stem() is now ".profile"
  • operator/ on path had its semantics changed significantly if the rhs is an absolute path or has a root-name. path("/foo") / "/bar" is now "/bar" rather than "/foo/bar"; path("C:\\x") / "D:y" on Windows is now "D:y".
  • The old absolute is gone. system_complete has been renamed absolute.
  • permissions's signature got a minor change.

Upvotes: 14

Related Questions