News for hackers. Stuff that matters.
Re:In-Memory Filesystems in Rust by 01HNNWZ0MV43FF on Monday August 25, 2025 @03:05AM (#45011105)
For context - cppreference.com doesn't say anything about `fstream` syncing on drop, but it does have an explicit `sync` function. `QFile` from Qt doesn't even have a sync function, which I find odd.
Re:In-Memory Filesystems in Rust by aw1621107 on Monday August 25, 2025 @05:04AM (#45011812)
I had always assumed that fstream flushes on destruction, but after digging through the standard all I can conclude is that I'm confused.

According to the standard, fstream doesn't have an explicit destructor, but the standard says "It uses a basic_filebuf<charT, traits> object to control the associated sequences." ~basic_filebuf(), in turn, is defined to call close() (which I think flushes to disk?) and swallow exceptions.

However, I can't seem to find anything that explicitly ties the lifetime of the fstream to the corresponding basic_filebuf. fstream doesn't have an explicitly declared destructor and the standard doesn't require that the basic_filebuf is a member of fstream, so the obvious ways the file would be closed don't seem to be explicitly required. In addition, all of fstream's parents' destructors are specified to perform no operations on the underlying rdbuf(). Which leaves... I don't know?

cppreference says the underlying file is closed, though, which should flush it. And that's what I would expect for an RAII class! But I just can't seem to find the requirement...