c++ - 为什么 std::filesystem 提供这么多非成员函数？

Question

举个例子 file_size .要获取文件的大小，我们将使用

std::filesystem::path p = std::filesystem::current_path();
// ... usual "does this exist && is this a file" boilerplate
auto n = std::filesystem::file_size(p);

这没什么不对，如果它是普通的 C，但被告知 C++ 是一种 OO 语言 [我知道它是多范式，向我们的语言律师道歉:-)] 感觉如此.. .势在必行(不寒而栗)对我来说，我已经开始期待对象式的

auto n = p.file_size();

相反。这同样适用于其他函数，例如 resize_file、remove_file 等等。

您知道为什么 Boost 和 std::filesystem 选择这种命令式风格而不是对象式风格的任何理由吗？有什么好处？升压mentions the rule (在最底部)，但没有理由。

我在考虑固有的问题，例如 remove_file(p) 之后的 p 状态，或错误标志(带有附加参数的重载)，但是这两种方法都无法解决这些问题比另一个优雅。

---

您可以观察到迭代器的类似模式，现在我们可以(应该？)执行 begin(it) 而不是 it.begin()，但是在这里我认为基本原理是更符合非修改 next(it) 等。

Answer 1

已经发布了几个很好的答案，但它们没有触及问题的核心:在所有其他条件相同的情况下，如果您可以将某些东西实现为免费的非友元函数，您总是应该这样做。

为什么？

因为，免费的非友元函数没有访问权限的特权。测试类比测试函数要难得多，因为您必须说服自己，无论调用哪些成员函数，甚至是成员函数的组合，类的不变量都会得到维护。您拥有的成员(member)/好友功能越多，您要做的工作就越多。

自由函数可以独立推理和测试。因为它们没有访问类状态的特权，所以它们不可能违反任何类不变量。

我不知道 path 允许哪些不变量和哪些特权访问的细节，但显然他们能够实现很多功能作为自由函数，他们做出了正确的选择并且做到了所以。

Scott Meyers brilliant article on this topic , 给出是否使函数成为成员的“算法”。

这是 Herb Sutter bemoaning the massive interface of std::string .为什么？因为，string 的大部分接口(interface)都可以作为自由函数实现。有时使用起来可能有点笨拙，但它更容易测试、推理、改进封装和模块化、为以前没有的代码重用打开机会等。