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

Question

在 C++17 文件系统库中，我们得到了std::filesystem::remove(path)，据我所知，它是boost::filesystem::remove(path)Boost.Filesystem的直接端口。

但是 C++ 从 C89 继承了一个非常相似的函数，称为std::remove(path)，它也被记录为一种从文件系统中删除文件的方法。我模糊地意识到这个函数的一些缺陷，例如，我相信我听说在 Windowsstd::remove上不能用于删除当前进程仍然保持打开状态的文件。

是否可以std::filesystem::remove解决这些问题std::remove？我宁愿std::filesystem::remove过std::remove？或者前者只是后者的命名空间同义词，具有相同的缺点和陷阱？

我的问题的标题询问了 和 之间的区别boost::filesystem::remove(path)，std::remove(path)因为我认为std::filesystem::remove(path)很多库供应商可能还没有实现，但我的理解是它应该基本上是 Boost 版本的直接副本。因此，如果您了解 Windows 上的 Boost.Filesystem，您可能也知道足以回答这个问题。

Answer 1

检查与我的 MSVC 一起安装的标准库源，std::experimental::filesystem::remove调用它的内部_Unlink助手，它只是调用_wremove，它只是调用 Windows DeleteFileW。同样，boost::filesystem::remove也只是DeleteFileW在 Windows 上调用。

std::filesystem::remove 是通过引用 POSIX 来指定的remove，但[fs.conform.9945] 中的全局措辞明确表明不需要实现来提供确切的 POSIX 行为：

实现应该提供 POSIX 定义的这种行为。实现应记录任何与 POSIX 定义的行为不同的行为。考虑到实际操作系统和文件系统的限制，不支持精确 POSIX 行为的实现应该提供尽可能接近 POSIX 行为的行为。如果一个实现不能提供任何合理的行为，则该实现应报告 [fs.err.report] 中指定的错误。[？笔记： [...] ]

实现不需要提供特定文件系统不支持的行为。[？例子： [...]？]

任何怪癖::remove（即关于删除的实际行为而不是要删除的文件的标识）都可能是由于底层 OS API 的限制。我认为没有理由认为std::filesystem::remove在同一操作系统上的实现会神奇地做得更好。