考虑以下关于路径分解的断言,其中每个局部变量例如: stem
有明显的初始化,例如auto stem = path.stem()
-
assert(root_path == root_name / root_directory);
assert(path == root_name / root_directory / relative_path);
assert(path == root_path / relative_path);
assert(path == parent_path / filename);
assert(filename == stem + extension);
这一切都有效,但最后一行除外 - 因为fs::path
没有定义operator+
。它有operator+=
,但没有operator+
。
这里的故事是什么?
我已经确定我可以通过添加自己的operator+
来编译此代码。有什么理由不这样做吗? (请注意,这是我自己的命名空间;我没有重新开放namespace std
。)
fs::path operator+(fs::path a, const fs::path& b)
{
a += b;
return a;
}
我对这个问题的唯一假设是:
也许设计师担心operator+
太容易与std::string
operator+
混淆。但这看起来很愚蠢,因为它在语义上完全相同(所以为什么要关心它是否会混淆?)。而且看起来设计师也不关心新手'当他们设计path.append("x")
从str.append("x")
和path.concat("x")
进行语义上不同的某些操作时,会产生混淆,以便在语义上做与{{1>相同的 }}
可能str.append("x")
隐式转化path
会导致某种operator string_type() const
变得含糊不清。但我一直无法提出任何此类案件。
答案 0 :(得分:2)
这是作为文件系统库的缺陷输入的,并且由于界面复杂性以及通过转换为字符串并返回到路径来解决的能力,因此判断它不是缺陷。在此处阅读所有相关内容:https://timsong-cpp.github.io/lwg-issues/2668