10
考慮以下關於路徑分解的斷言，其中每個局部變量例如stem具有明顯的初始化，例如auto stem = path.stem() -爲什麼boost :: filesystem :: path和std :: filesystem :: path缺少operator +？
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")做一些語義相同爲str.append("x")。也許
path的隱式轉換operator string_type() const會導致某些變種p + q變得含糊不清。但是我一直無法想出任何這樣的案例。
https://timsong-cpp.github.io/lwg-issues/2668 –
來自上述鏈接的基本原理：*「basic_string運算符所需的12個重載+使我感到害怕，而且我永遠不會回到了這個問題。「*胡。像''那樣巨大，我真的沒有想到，「懶惰，懶惰」將成爲最終的答案！ ：P –
Quuxplusone
這不完全是懶惰，但在考慮過載的次數時會害怕*。我們已經抱怨，當我們現在有'string_view'時，12個'string'重載是不夠的 - 沒有'string' +'string_view'。這裏會有很多很多。一旦你有'path' +'path'，有人會要求'path' +'string'（在Windows上是'path' +'wstring'），'path' +'string_view'，'path' +'const char *'，'path' +'char'。然後當然'string' +'path'等將數字加倍。整個批次的左值和右值版本。 –