简体繁体 English

std::remove 和 boost::filesystem::remove 的区别？

[英]Difference between std::remove and boost::filesystem::remove?

原文 2017-09-06 03:21:34 5 1 c++/ visual-studio/ boost/ file-handling

In the C++17 filesystem library, we got std::filesystem::remove(path) , which — as I understand it — is a direct port of boost::filesystem::remove(path) from Boost.Filesystem.在 C++17 文件系统库中，我们得到了std::filesystem::remove(path) ，据我所知，它是 Boost.Filesystem 的boost::filesystem::remove(path)的直接端口。

But C++ inherited from C89 a very similar function called std::remove(path) , which is also documented as a way to remove a file from the filesystem.但是 C++ 从 C89 继承了一个非常相似的函数std::remove(path) ，它也被记录为一种从文件系统中删除文件的方法。 I'm vaguely aware of some pitfalls with this function, eg I believe I have heard that on Windows std::remove cannot be used to remove a file that is still being held open by the current process.我模糊地意识到这个函数的一些缺陷，例如我相信我听说在 Windows 上std::remove不能用于删除当前进程仍然保持打开状态的文件。

Does std::filesystem::remove fix these issues with std::remove ?不会std::filesystem::remove修复这些问题std::remove ？ Should I prefer std::filesystem::remove over std::remove ?我应该更喜欢std::filesystem::remove不是std::remove吗？ Or is the former just a namespaced synonym for the latter, with the same warts and pitfalls?或者前者只是后者的命名空间同义词，具有相同的缺点和陷阱？

The title of my question asks for the difference between boost::filesystem::remove(path) and std::remove(path) because I figure that std::filesystem::remove(path) may not have been implemented by a lot of library vendors yet, but my understanding is that it's supposed to be basically a direct copy of the Boost version.我的问题的标题要求boost::filesystem::remove(path)和std::remove(path)之间的区别，因为我认为std::filesystem::remove(path)可能没有被很多人实现库供应商，但我的理解是它应该基本上是 Boost 版本的直接副本。 So if you know about Boost.Filesystem on Windows, you probably know enough to answer this question too.因此，如果您了解 Windows 上的 Boost.Filesystem，您可能也知道足以回答这个问题。

1 个解决方案

Checking the standard library sources installed with my MSVC, std::experimental::filesystem::remove calls its internal _Unlink helper, which simply calls _wremove , which simply calls Windows DeleteFileW . 检查用我的MSVC安装的标准库源， std::experimental::filesystem::remove调用它的内部_Unlink助手， _Unlink调用_wremove ， _wremove调用Windows DeleteFileW 。 Similarly, boost::filesystem::remove also just calls DeleteFileW on Windows. 同样， boost::filesystem::remove也只是在Windows上调用DeleteFileW 。

std::filesystem::remove is specified by reference to POSIX remove , but the global wording in [fs.conform.9945] makes clear that implementations are not required to provide the exact POSIX behavior: std::filesystem::remove 通过参考指定POSIX remove ，但在全球措词[fs.conform.9945]清楚地表明，实施方式不要求提供确切POSIX行为：

Implementations should provide such behavior as it is defined by POSIX. 实现应该提供POSIX定义的行为。 Implementations shall document any behavior that differs from the behavior defined by POSIX. 实现应记录与POSIX定义的行为不同的任何行为。 Implementations that do not support exact POSIX behavior should provide behavior as close to POSIX behavior as is reasonable given the limitations of actual operating systems and file systems. 由于实际操作系统和文件系统的限制，不支持精确POSIX行为的实现应提供尽可能接近POSIX行为的行为。 If an implementation cannot provide any reasonable behavior, the implementation shall report an error as specified in [fs.err.report]. 如果实现无法提供任何合理的行为，则实现应报告[fs.err.report]中指定的错误。 [ Note: [...] ] [ 注意： [...] ]

Implementations are not required to provide behavior that is not supported by a particular file system. 不需要实现来提供特定文件系统不支持的行为。 [ Example: [...] ] [例如：[...]]

Any quirks in ::remove (that is about the actual act of removing rather than identification of the file to be removed) are likely due to limitations of the underlying OS API. ::remove任何怪癖（这是关于删除而不是识别要删除的文件的实际行为）可能是由于底层OS API的限制。 I see no reason to think that an implementation of std::filesystem::remove on the same operating system will magically do better. 我认为没有理由认为在同一操作系统上执行std::filesystem::remove会神奇地做得更好。

Before something appears in STL, they could test it in boost.在 STL 中出现某些东西之前，他们可以在 boost 中对其进行测试。 If it is usable or not, etc... So it is preferable to use STL as it is a part of the language.如果它可用或不可用等等......所以最好使用STL，因为它是语言的一部分。