在C ++ 17文件系统库中，我们得到了std::filesystem::remove(path)，据我所知，它是来自Boost.Filesystem的boost::filesystem::remove(path)的直接端口。
但是C ++从C89继承了一个非常类似的函数std::remove(path)，也记录了从文件系统中删除文件的方法。我隐约意识到这个功能的一些缺陷，例如：我相信我听说在Windows上std::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，您可能也足够了解这个问题。
答案 0 :(得分：3)
检查随MSVC安装的标准库来源，std::experimental::filesystem::remove调用其内部_Unlink帮助程序，只需调用_wremove即可调用Windows DeleteFileW。同样，boost::filesystem::remove也只是在Windows上调用DeleteFileW。
std::filesystem::remove is specified by reference to POSIX remove，但[fs.conform.9945]中的全局措辞表明，实现不需要提供确切的POSIX行为：
实现应提供由其定义的行为 POSIX。实现应记录任何不同的行为 POSIX定义的行为。不支持的实现 确切的POSIX行为应该提供接近POSIX的行为 鉴于实际操作的限制，行为是合理的 系统和文件系统。如果实现无法提供任何合理的行为，则实现应报告[fs.err.report]中指定的错误。 [注：[...]]
不需要实现来提供特定文件系统不支持的行为。 [例如：[...]]
::remove中的任何怪癖（这是关于删除而不是识别要删除的文件的实际行为）可能是由于底层OS API的限制。我认为没有理由认为在同一操作系统上std::filesystem::remove的实现会神奇地做得更好。