C++ says “We have try... finally at home”

Post by mandarax8 » Sun, Dec 28, 2025, 1:23 PM UTC

winternewt wrote: post #21

Destructors are vastly superior to the finally keyword because they only require us to remember a single time to release resources (in the destructor) as opposed to every finally clause. For example, a file always closes itself when it goes out of scope instead of having to be explicitly closed by the person who opened the file. Syntax is also less cluttered with less indentation, especially when multiple objects are…

Post by mojuba » Sun, Dec 28, 2025, 1:28 PM UTC

Someone wrote: post #48

mojuba wrote: post #3

I like how Swift solved this: there's a more universal `defer { ... }` block that's executed at the end of a given scope no matter what, and after the `return` statement is evaluated if it's a function scope. As such it has multiple uses, not just for `try ... finally`.

I think Swift’s defer ( https://docs.swift.org/swift-book/documentation/the-swift-pr... ) was inspired by/copied from go ( https://go.dev/tour/flowcontrol/12 ), but they may have taken it from an even earlier language that I’m not aware of. Defer has two advantages over try…finally: firstly, it doesn’t introduce a nesting level. Secondly, if you write foo defer revert_foo , when scanning the code, it’s easier to veri…

    busy = true
    Task {
        defer { busy = false }
        // do async stuff, possibly throwing exceptions and whatnot
    }

Post by kibwen » Sun, Dec 28, 2025, 1:34 PM UTC

mojuba wrote: post #33

dwattttt wrote: post #6

Earlier quoted context omitted.

I was contemplating what it would look like to provide this with a macro in Rust, and of course someone has already done it. It's syntactic sugar for the destructor/RAII approach. https://docs.rs/defer-rs/latest/defer_rs/

I don't know Rust but, can this `defer` evaluate after the `return` statement is evaluated like in Swift? Because in Swift you can do this: func atomic_get_and_inc() -> Int { sem.wait() defer { value += 1 sem.signal() } return value }

    struct PrintOnDrop;
    
    impl Drop for PrintOnDrop {
        fn drop(&mut self) {
            println!("dropped");
        }
    }
    
    fn main() {
        let p = PrintOnDrop;
        return println!("returning");
    }

Post by speed_spread » Sun, Dec 28, 2025, 1:51 PM UTC

deliciousturkey wrote: post #14

tryfinally wrote: post #4

I always wonder whether C++ syntax ever becomes readable when you sink more time into it, and if so - how much brain rewiring we would observe on a functional MRI.

In my opinion, C++ syntax is pretty readable. Of course there are codebases that are difficult to read (heavily abstracted, templated codebases especially), but it's not really that different compared to most other languages. But this exists in most languages, even C can be as bad with use of macros. By far the worst in this aspect has been Scala, where every codebase seems to use a completely different dialect of th…

Post by DonHopkins » Sun, Dec 28, 2025, 2:01 PM UTC

mandarax8 wrote: post #52

winternewt wrote: post #21

Destructors are vastly superior to the finally keyword because they only require us to remember a single time to release resources (in the destructor) as opposed to every finally clause. For example, a file always closes itself when it goes out of scope instead of having to be explicitly closed by the person who opened the file. Syntax is also less cluttered with less indentation, especially when multiple objects are…

The entire point of the article is that you cannot throw from a destructor. Now how do you signal that closing/writing the file in the destructor failed?