Implementing Go's defer keyword in C++

Re:Implementing Go's defer keyword in C++ by nothrabannosir on Saturday October 21, 2017 @05:39PM (#15523751)

con: "finally" puts the cleanup code at the end of the function. With "defer" you have it scattered at the beginning.

Quite commonly an advantage, e.g.:

    f, err := openFile('...')
    if err != nil {
        ...
    }
    defer f.Close()

is how it's commonly used. This makes sense because the cleanup lives next to the initialization of the actual thing it's cleaning up. In a way it becomes part of the initialization, itself.

Same with locks and release. Now you don't have to scan across the entire function body to make sure your inits and cleanups match up.

[ Parent | on HN ]

Re:Implementing Go's defer keyword in C++ by albinofrenchy on Saturday October 21, 2017 @08:37PM (#15524458)

There is a substantial issue with this pattern for things like files -- the operating system imposes a max limit on the number of file descriptors you can have open.

Defer gives no guarantees about when that thing is going to run -- just that it is after the function returns. Because of this, you can get erratic behavior if you open and defer closing a lot; essentially openFile just stops working at some point.

This can happen with any limited resource and isn't theoretical; I had a friend who ran into this in long running process with a lot of IO.

[ Parent | on HN ]

Re:Implementing Go's defer keyword in C++ by nothrabannosir on Sunday October 22, 2017 @03:02AM (#15525541)

Defer statements run exactly at the moment of a function return (in lifo order). They are equivalent to wrapping the rest of the function body in a try / finally. They have to, since you can change the return value in a defer (by using named return values).

A "defer" statement invokes a function whose execution is deferred to the moment the surrounding function returns, either because the surrounding function executed a return statement, reached the end of its function body, or because the corresponding goroutine is panicking.

https://golang.org/ref/spec#Defer_statements

There might have been something else going on with your friend's code. Maybe the function he was using didn't return before running out of file descriptors?

[ Parent | on HN ]

Re:Implementing Go's defer keyword in C++ by albinofrenchy on Sunday October 22, 2017 @02:22PM (#15528153)

I somehow completely misunderstood that from the Go documentation when first reading it; thank you for clarifying that.

There must have been some other leaking going on. He was using a largish library when he saw the leak and eventual crash so maybe it was due to improper pooling or C api calls? I'll have to ask him more about it.

[ Parent | on HN ]

Re:Implementing Go's defer keyword in C++ by int_19h on Saturday October 21, 2017 @11:00PM (#15524936)

Isn't it guaranteed to run at the exact point where the function in which "defer" was used returns?

[ Parent | on HN ]

Re:Implementing Go's defer keyword in C++ by albinofrenchy on Sunday October 22, 2017 @02:18PM (#15528132)

I was wrong, apparently it is. Really wish there was a way to edit that comment now.

[ Parent | on HN ]