考虑以下关于路径分解的断言,其中每个局部变量例如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
's operator+
。但这看起来很愚蠢,因为它在语义上做了完全相同的事情(所以为什么要关心它是否会被混淆呢?)。而且设计者在设计时似乎并没有考虑到新手的困惑path.append("x")
从语义上做某事不同的 from str.append("x")
and path.concat("x")
从语义上做某事the same as str.append("x")
.
Maybe path
的隐式转换operator string_type() const
会引起一些各种各样的p + q
变得暧昧。但我一直无法想出任何这样的案例。
这是作为文件系统库的缺陷输入的,由于接口的复杂性以及通过转换为字符串和返回路径来解决问题的能力,它被判断为不是缺陷。在这里阅读所有相关内容:https://timsong-cpp.github.io/lwg-issues/2668 https://timsong-cpp.github.io/lwg-issues/2668
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)