Lightning Talk: To Flush or Not to Flush? - That Is the Question
summary
Writes a simple file example that fails against /dev/null and reveals that ofstream destructor flush hides errors, so programs can report success when flush actually failed. Shows a real outage where writing then renaming produces a partially formed file because rename guard that atomically publishes mixes finalization with cleanup. Builds a scope-based guard, wrestles with returning non-copyable PR values, avoids throwing from destructors by disarming the guard in a try/catch, and ends with a working pattern.
AI-written summary · about
related talks
01h 01mRacing The File System
01h 08m“Declarative Control Flow"
40mLessons from two decades of writing bad code
01h 13m"Mostly Invalid": flat_map, Exception Guarantees, and the STL
36mInterfaces Matter
57m“The Unexceptional Exceptions"
05mLightning Talk: Disentangling The Mikado Method When Refactoring C++ Legacy Code
01h 20mBetter Code: Relationships