In normalizing c++17 filesystem use in my code, I found it much nicer than my experiences with rust's equivalent might suggest. From rust I kept having to unwrap layers and convert string types a lot. std::filesystem::path and directory_entry may even have as many layers and complexity as rusts, but it feels much easier and more automatic to actually work with. I especially appreciate I can write a directory scan as a stl algorithm and execute filenames in a lambda. For example:
namespace fsys = std::filesystem;
inline auto scan_dir(const fsys::path& path, std::function<bool(const fsys::directory_entry&)> proc) {
auto dir = fsys::directory_iterator(path);
return std::count_if(begin(dir), end(dir), proc);
}
What kept me from using c++17 filesystem support was poor gcc support for a long time, including having it as a separate runtime library, and it's similarly late introduction in clang. I currently have similar problems with adapting use of c++20 modules, but probably will rewrite things using that in a few years, as, like header libraries, it makes auto type deduction much more valuable. Header-less code means less duplication, and to me it would make c++ even more preferable to coding than rust.
Whats important to remember is that many enterprise gnu/linux distros have very long lifespans. They keep older compilers and versions of languages alive a lot longer with them, too. I now target bullseye (debian 11/gcc 10) or later, though my code can still build on suse (including openSUSE leap) and netbsd 9, both of which still default with gcc < 10 and c++ libraries built from that. Old system releases never die...
Top comments (3)
Nothing prevents you from installing the compiler version of your choice on Linux systems. You're not stuck with whatever the distro has. Typically, I build my own compilers from source (using the distro compiler), then uninstall the distro compiler.
You are to some extent if you are building things that link with libraries prebuilt on the distro itself. ABI layouts change (more often this comes up in C++ where name mangling rules change) for example. In the case of filesystem, it is also a libstdc++ runtime change as well.
/usr/local/bin/gccwhen you want. (However, I've found that this usually causes problems with the wrong compiler being used becausePATHisn't set correctly to pick up/usr/local/binbefore/usr/bin.)For production software, you certainly don't want the distro maintainers to dictate which compiler version you use. You always want to have total control over your compiler toolchain and upgrade it only on your schedule.