同版本Clang在不同操作系统下编译结果不同的原因

核心原因 #

Windows和macOS平台上，std::filesystem::path的字符类型默认存在差异：

• macOS环境下，std::filesystem::path的value_type是char，和std::string的底层字符类型完全一致，因此可以直接用path对象初始化std::string。
• Windows环境下，std::filesystem::path的value_type默认是wchar_t（Windows系统原生采用宽字符处理路径），而std::string是基于char的basic_string实例，两者类型不匹配，编译器找不到对应的构造函数重载，因此报出"no matching constructor"错误。

解决方法 #

要在Windows上实现path到std::string的转换，直接调用std::filesystem::path的string()成员函数即可，该函数会自动将宽字符路径转换为窄字符的std::string：

#include <filesystem>

int main()
{
  std::filesystem::path p("/some/path");
  std::string s(p.string()); // 使用path的string()成员函数完成类型转换
}

如果需要兼容宽字符场景，也可以使用wstring()成员函数初始化std::wstring，但根据你的需求，string()是最直接且符合跨平台逻辑的解决方案。

另外，也可以通过编译宏强制Windows上的std::filesystem::path使用char作为value_type（比如编译时添加-D_FILESYSTEM_CHAR_T=char参数），但这种方式可能和Windows系统原生路径处理逻辑冲突，不推荐使用。

内容的提问来源于stack exchange，提问作者mvc