c++ - 为什么 boost::filesystem::canonical() 需要目标路径存在?

标签 c++ boost boost-filesystem c++17

boost::filesystem::canonical(const path& p) 的文档状态:

Overview: Converts p, which must exist, to an absolute path that has no symbolic link, dot, or dot-dot elements.
...
Remarks: !exists(p) is an error.

这样做的结果是,如果 p 标识了一个目标不存在的符号链接(symbolic link),则函数将失败并返回 file not found 并且不返回路径。

这对我来说似乎过于严格:仅仅因为链接的目标不存在,我看不出函数无法解析该不存在目标的 path 的原因。 (相比之下,absolute() 没有这样的限制。)

(显然,如果路径的符号链接(symbolic link)被破坏,则无法解析目标路径。)

那么,这种限制是否有正当理由?

即使有,是否也有理由创建一个没有此限制的函数变体? (如果没有这样的变体,获取路径需要手动复制 canonical() 已经完成的 99% 的操作,容易出错。)

我很欣赏 stat()lstat() 之间存在的语义微妙之处同样适用于这种情况 - 这正是我认为该函数的变体的原因同样有道理。

注意:这个问题同样适用于 std::experimental::filesystem 库 ( n4100 ),它基于 boost::filesystem

编辑:

在下面@Jonathan Wakeley 的知识渊博的回答之后,我仍然保留了我最初问题的本质,我将稍微重新构建:

  • boost::filesystem::canonical() 是否存在潜在的技术或逻辑原因?我的意思是,目标的不存在是否会导致无法解析规范形式的路径?

  • 如果没有,是否有任何技术或逻辑原因提出仅与现有形式不同的功能变体要求目标存在?

  • 在将 boost::filesystem 转换为提议的 N4100 std::experimental::filesystem 的过程中(据我所知),有这个对 canonical() 的限制是经过充分考虑后才被采纳的,还是只是从 Boost 定义中“落空”?

编辑 2:

我注意到 Boost 1.60 现在提供了函数 weakly_canonical():“返回 p,符号链接(symbolic link)已解析,结果标准化。返回:由调用 canonical( ) 在由 p 的前导元素组成的路径上的函数,如果存在的话,然后是 p 的不存在的元素,如果有的话。"

编辑 3:

More discussion of this关于 std::filesystem.

最佳答案

试试weakly_canonical()它不需要在mac上存在路径

关于c++ - 为什么 boost::filesystem::canonical() 需要目标路径存在?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31337832/

相关文章:

c++ - 重用线程 - boost 与标准线程行为

c++ - 在线程之间发送字符串数据 (Win32)

r - 在 RStudio 0.99 上使用 BH 包的 Rcpp 函数中的 boost 日期出现问题

c++ - 在 C++ 中将数据作为 void* 传递

php - PHP 或 C 中的压缩和加密

c++ - boost::option_description 获取默认值

c++ - 使用boost的字节序转换

c++ - Boost文件系统编译错误

c++ - 为什么我还必须使用 -lstdc++fs?

c++ - boost 路径指向的目录中文件的路径