为什么boost :: filesystem :: path和std :: filesystem :: path缺少运算符+？ [英] Why do boost::filesystem::path and std::filesystem::path lack operator+?

问题描述

请考虑以下有关路径分解的断言，其中每个局部变量例如词干具有明显的初始化功能，例如自动词干= path.stem（） —

Consider the following assertions about path decomposition, where each local variable e.g. stem has the obvious initialization e.g. 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 + 。

This all works, except for the last line — because fs::path does not define an operator+. It has operator+=, but no operator+.

这里的故事是什么？

我确定可以通过添加自己的<$ c $来使此代码编译c> operator + 。有什么理由不这样做吗？ （注意，这是在我自己的命名空间中；我不会重新打开命名空间std 。）

I've determined that I can make this code compile by adding my own operator+. Is there any reason not to do this? (Notice this is in my own namespace; I'm not reopening namespace std.)

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

关于这个问题，我唯一的假设是：

My only hypotheses on the subject are:

• 也许设计师担心 operator + 容易与 std混淆： ：string 的 operator + 。但这似乎很愚蠢，因为它在语义上做完全相同的事情（所以为什么要关心它是否被合并？）。而且，当设计师设计 path.append（ x）进行语义上不同的操作时，他们似乎并不在乎新手的困惑。 >从 str.append（ x）和 path.concat（ x）中进行语义上的操作与 str.append（ x）相同。

• Maybe the designers worried that operator+ would be too easily confused with std::string's operator+. But that seems silly, since it does exactly the same thing semantically (so why care if it gets conflated?). And it also seems that the designers didn't care about newbies' confusion when they designed path.append("x") to do something semantically different from str.append("x") and path.concat("x") to do something semantically the same as str.append("x").

也许路径的隐式转换运算符string_type（）const 会导致某些 p + q 变得模棱两可。但是我一直无法提出这样的案例。

Maybe path's implicit conversion operator string_type() const would cause some variety of p + q to become ambiguous. But I've been unable to come up with any such case.

推荐答案

这被认为是文件系统库的缺陷，并且由于接口的复杂性和通过转换为字符串再返回到路径的解决方法的能力，被认为不是缺陷。在这里阅读所有内容： https://timsong-cpp.github.io/lwg- Issues 2668

This was entered as a defect against the filesystem library, and because of the interface complexity and the ability to work around by converting to strings and back to paths, it was judged to not be a defect. Read all about it here: https://timsong-cpp.github.io/lwg-issues/2668

这篇关于为什么boost :: filesystem :: path和std :: filesystem :: path缺少运算符+？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！