¿Por qué boost :: filesystem :: path y std :: filesystem :: path carecen de operador +?
Considere las siguientes afirmaciones sobre la descomposición de la ruta, donde cada variable local, p.stem
tiene la inicialización obvia p.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);
Todo esto funciona, excepto la última línea, porquefs::path
no define unoperator+
. Tieneoperator+=
, pero nooperator+
.
¿Cuál es la historia aquí?
He determinado que puedo compilar este código agregando el míooperator+
. ¿Hay alguna razón para no hacer esto? (Observe que esto está en mi propio espacio de nombres; no voy a volver a abrirnamespace std
.)
fs::path operator+(fs::path a, const fs::path& b)
{
a += b;
return a;
}
Mis únicas hipótesis sobre el tema son:
Quizás a los diseñadores les preocupaba queoperator+
se confundiría demasiado fácilmente constd::string
'soperator+
. Pero eso parece una tontería, ya que hace exactamente lo mismo semánticamente (entonces, ¿por qué preocuparse si se combina?). Y también parece que a los diseñadores no les importó la confusión de los novatos cuando diseñaronpath.append("x")
hacer algo semánticamentediferente destr.append("x")
ypath.concat("x")
hacer algo semánticamentelo mismo comostr.append("x")
.
Tal vezpath
conversión implícitaoperator string_type() const
causaría alguna variedad dep + q
volverse ambiguo Pero no he podido llegar a tal caso.