我有一个目前使用C++ 11/14的项目,但它需要类似的东西std::filesystem,它只在C++ 17中可用,因此我没有机会当前使用它.但是,我看到它在我当前的编译器中可用std::experimental::filesystem.使用实验性功能是一个好主意,假设我将来可以添加如下内容:
#ifdef CXX17 //if this is C++17
std::filesystem::something ...;
#else
std::experimental::filesystem::something ...;
#endif
我担心的是:
1.是否保证所有兼容编译器具有相同的实验功能？
2.实验性特征是否容易发生重大变化,使其不可靠？
也许还有更多值得关注的事情.我为什么要或不应该使用它们？我对一个新项目感到困惑,不知道该决定什么.
我需要一个文件系统库,用于支持C++ 11的编译器或支持C++ 14的编译器 - 所以它不能来自C++ 17.
现在,我知道进入C++ 17的文件系统库是基于Boost :: Filesystem的; 但是 - 它们是否足够相似,我可以使用Boost库,然后在以后无缝切换到标准版本,而不会更改,比如using声明？或两者之间是否存在(轻微/重大)差异？我知道,对于这种情况variant,Boost和标准库版本有很大不同.
给出以下代码：
#include <iostream>
#include <filesystem>
namespace fs = std::filesystem;
int main()
{
fs::path fsBase = "/base";
fs::path fsAppend = "/append";
auto fsResult = fsBase / fsAppend;
std::cout << "fsResult: " << fsResult << std::endl;
return 0;
}
通常，预期的结果是/base/append，但它实际上给出了/append。
fs::path::append的描述确实表明了这种行为：
如果 p.is_absolute() || (p.has_root_name() && p.root_name() != root_name())，然后用 p 替换当前路径，就像用 operator=(p) 并完成一样。
然而，行为std::experimental::filesystem和boost::filesystem不同的是，这给了预期/base/append。请参阅示例。
问题是为什么它会这样？为什么用append()函数替换路径？
现在，在“升级”到“更新”版本的编译器之后，我没想到会这样。
在 VS2017 中 std::filesystem 可通过 std::experimental::filesystem 获得，现在升级到 VS2019 后令我惊讶的是它根本不可用。不在 std::experimental 或 std::filesystem 中。
是的，我已经尝试从项目的设置中设置 c++17，甚至是“最新草案”的东西，有什么想法吗？