Question Details

No question body available.

Tags

c++ c++17

Answers (3)

June 29, 2026 Score: 6 Rep: 66,870 Quality: Medium Completeness: 40%

std::filesystem applies to non-POSIX systems. Presumably some implementers pushed back on providing file size as part of file_status, because on those platforms there would be extra work.

June 29, 2026 Score: 5 Rep: 5,560 Quality: Low Completeness: 0%

C++ is also used on non-POSIX platforms.

June 29, 2026 Score: 2 Rep: 2,060 Quality: Low Completeness: 60%

My question is: Why did they decide to omit size() fromfilestatus?

This is because filestatus maps to just the stmode field of struct stat (which contains precisely this information) and not the entirety of struct stat. It just happens to be the case that POSIX specifies that stmode encodes both the file type as well as the standard POSIX permissions in a single field. And because it is a single field in POSIX, std::filesystem also defined a structure containing both at the same time.

In general, std::filesystem is designed in such a manner that anything you can query of a file will correspond to at most a single field of struct stat per method, or a subset thereof (such as isdirectory() will only give you partial information from filestatus()), but never a combination of more than a single entry.

In the end, std::filesystem is an imperfect design, but much better than anything that C++ had beforehand. In many cases the design flaws in std::filesystem aren't really that impactful, because most software doesn't perform a huge amount of filesystem operations at once, where this would matter. But if it does matter for your use case, I would recommend you write your own abstraction for precisely the operations that you need, and just call the low-level system calls in the implementation of that abstraction.

However, I noticed that if I use fs::directoryentry during iteration, entry.filesize() returns a cached value without making an extra syscall

How are you verifying this? The only place I see this happening is on Windows, because the FindFirstFile() (and related) APIs already provide that information for each entry upon enumeration, so that information can easily be returned for each entry without another system call.

This is similar to how POSIX returns both the file name and the file type with readdir(), so even there it's more than just the name, albeit not quite as much information as Windows does. On those systems though, calling fs::directoryentry::filesize() will result in an additional syscall being issued for that file. I can easily verify that when I run a simple program through strace on Linux or dtruss on macOS, and on Linux it doesn't matter whether I use GCC with libstdc++ or Clang with libc++. Reading the source code of libstdc++ and libc++ also confirms this.