c++14 std::experimental::filesystem::v1 和 c++17 std::filesystem 的区别？答案

【问题标题】：Differences between c++14 std::experimental::filesystem::v1 and c++17 std::filesystem?c++14 std::experimental::filesystem::v1 和 c++17 std::filesystem 的区别？
【发布时间】：2018-01-19 18:44:16
【问题描述】：

我找到了这个页面，描述了c++14和c++17的变化：

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

...它链接到此页面，该页面描述了建议的文件系统更改：

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

我浏览了一下。标准有一些小的措辞更改，但我看到的唯一代码更改是命名空间更改，删除了“实验”和“v1”部分，因此“std::experimental::filesystem::v1”变成了“std::filesystem "，这是预期的。

据我所知，除了命名空间路径没有任何变化。有谁知道是否还有其他变化？

换句话说，我正在使用带有 -std=c++14 的 gcc。我现在可以使用 std::experimental::filesystem 编写代码，并且将来只需更改此命名空间即可轻松切换到 -std=c++17 吗？

我能找到的最接近重复的问题：

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

【问题讨论】：

找出答案的一种方法：使用它！
我认为，正确答案的最大希望是直接在 GCC 网站上提出这个问题。您确实需要对 libstdc++ 内部实现有深入的了解才能回答这个问题，而且在它的开发人员群体之外，您不会发现有那么多人有这方面的知识。
你浏览的那篇论文几乎全是importing Boost.Filesystem，所以关于Boost的问题和这篇回答差不多。

标签： c++ c++14 c++17

【解决方案1】：

对文件系统库进行更改的主要论文是

P0219R1，添加相对路径支持
P0317R1，将缓存添加到directory_entry
P0492R2，一长串针对国家机构 cmets 的修复和更改列表
P0430R2，支持某些非 POSIX 系统

还有一些相对较小的修复和更改可以在in the LWG issue list 找到。查找“C++17”状态的问题。请注意，其中一些更改随后会被上面列出的文件所取代。

对于现有的文件系统 TS 代码，我希望 P0492R2 是最重要的，因为剩下的论文主要是功能添加而不是更改。 P0492R2 包括技术说明和重大语义更改。后一类中的一些立即浮现在脑海中的是：

path(".profile").stem() 现在是 ".profile"
如果 rhs 是绝对路径或具有根名称，path 上的 operator/ 的语义会发生显着变化。 path("/foo") / "/bar" 现在是 "/bar" 而不是 "/foo/bar"； Windows 上的 path("C:\\x") / "D:y" 现在是 "D:y"。
旧的absolute 不见了。 system_complete 已重命名为 absolute。
permissions 的签名略有改动。

【讨论】：

operator/ 语义很危险。如果"/bar" 来自用户输入，则用户可以覆盖该进程用户拥有的系统中的任何文件。
@balki 这毫无意义。即使使用旧语义，用户也可以在前面添加任意数量的../，以达到相同的目的。
如果 p 是绝对路径，为什么append(p) 会替换原始路径，这真的很令人困惑，请参阅stackoverflow.com/questions/55214156

【解决方案2】：

延迟回复，但当我自己寻找同一问题的答案时，我遇到了这个问题。当我终于弄清楚事情的时候，我想我会在这里发表我的观察。

从std::experimental::filesystem 迁移到std::filesystem 时，我遇到了以下变化：

#	c++14 `std::experimental::filesystem`	c++17 `std::filesystem`
1	`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
2	`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`
3	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.
4	`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`.

【讨论】：