c-为什么boost :: filesystem :: path和std :: filesystem :: path缺少运算符?

考虑以下有关路径分解的断言,其中每个局部变量例如词干具有明显的初始化功能,例如自动词干= 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.

这是什么故事?

我确定可以通过添加自己的运算符来使此代码编译.有什么理由不这样做吗? (请注意,这是在我自己的名称空间中;我没有重新打开名称空间std.)

fs::path operator+(fs::path a, const fs::path& b)
{
    a += b;
    return a;
}

关于这个问题,我唯一的假设是:

>也许设计师担心操作符与std :: string的操作符容易混淆.但这似乎很愚蠢,因为它在语义上做完全相同的事情(所以为什么要关心它是否被合并?).而且似乎设计师在设计path.append(“ x”)来执行从str.append(“ x”)和path.concat(“ x”)到语义上有所不同的事情时,设计师也不在乎新手的困惑.在语义上与str.append(“ x”)相同.
>也许路径的隐式转换运算符string_type()const会导致p q的某些变化变得模棱两可.但是我一直无法提出任何这样的案例.

解决方法:

这是作为文件系统库的缺陷输入的,并且由于接口的复杂性以及通过转换为字符串然后返回路径来解决的能力,因此认为它不是缺陷.在这里阅读所有内容:https://timsong-cpp.github.io/lwg-issues/2668

上一篇:c – std :: experimental :: is_detected的奇怪MSVC行为


下一篇:c-VS 2017程序无法识别“ scoped_lock”