Boost文件系统和标准C ++文件系统库有多相似？

Question

我需要一个文件系统库，用于支持C ++ 11的编译器或支持C ++ 14的编译器 - 因此它不能来自C ++ 17。

现在，我知道进入C ++ 17的文件系统库是基于Boost :: Filesystem的;但是 - 它们是否足够相似，我可以使用Boost库，然后在以后无缝切换到标准版本，而不会改变超过using语句？或两者之间是否存在（轻微/重大）差异？我知道对于variant的情况，Boost和标准库版本有很大不同。

Answer 1

有许多不同之处。我相信，有些人是从未传播的促进变革。例如，没有path.filename_is_dot()查询（如下所述，无论如何，它在std::filesystem中都不太有用）。

在这方面还有一些最新消息：

1. 支持non-POSIX-like filesystems：
   • 指定字符串是OS本机还是POSIX（或者让实现决定，这仍然是（仍然是）默认值）
   • 实现可以定义其他文件类型（超出常规，目录，套接字，等。）
   • 实现可以为目录或设备文件定义file_size
2. filename(), normalization, and relative/absolute conversions redefined（POSIX的示例）：
   • path("foo/.").lexically_normal()=="foo/"（与Boost相反）
   • path("foo/").filename()==""（Boost中path(".")）
   • remove_filename()留下尾随斜杠，因此是幂等的（它在Boost中指定parent_path()）
   • path(".profile").extension()==""（是Boost中的全名）
   • path分解和组合可以保留通常不可见的alternate data stream names之类的内容
   • path("foo")/"/bar"=="/bar"（在Boost中为path("foo/bar")），允许与其他人（绝对或相对）合成相对文件名并替换Boost＆＃39; absolute()
   • Boost＆＃39; system_complete()（只有一个参数）重命名为absolute()
   • canonical()因此只需要一个参数（在DR中修复）
   • lexically_relative()正确处理..和根元素
   • permissions()需要更多参数（Boost将它们组合成一个位掩码）

请注意，Boost.Filesystem v4是under development，并且应该与C ++ 17兼容（但因此在许多方面与v3不兼容）。

Answer 2

警告：这个答案并不反映C ++ 17最终确定之前的几个最后更改。请参阅@ DavisHerring的回答。

Boost文件系统插件和提取器使用&作为"和&的转义字符。

该标准将使用std::quoted（默认情况下使用\）来转义"，后者又使用\\来转义\，请参阅{ {3}}

this reference

它们之间可能只有一个区别。

可以在Demo

找到造成这种差异的原因