6 ms·

I don't mind a sane defer in C, that is something which follows scope in the same way stack allocated destructors are invoked. This follows the behaviour in oth

by lerno 5y ago

I don't mind a sane defer in C, that is something which follows scope in the same way stack allocated destructors are invoked. This follows the behaviour in other languages like Swift. Why "on function exit" style defers - already known to be a bad idea from Go - is beyond me. Such a solution more or less requires storage of potentially unbounded allocations. Foo *f; for (int i = 0; i < very_big_value; i++) { f = get_foo(i); // BOOM defer return_foo(f); } I would sort of understand if this was proposed for a high level language garbage collection where actual memory usage is secondary.

cpuguy83 5y ago
In this case you wrap the loop in an anonymous function if you need it to be cleaned up within the scope of the loop. Or move the functionality to another function.
- knome 5y ago
  Adding a statement that would require a dynamic allocation for every iteration of a loop is kind of insane for C. It doesn't matter what the defer does, if it's allocated in a for statement and doesn't go off until the surrounding function exits, then it's going to have to stuff tons of function pointers and parameters somewhere, presumably alloca'd onto the stack over and over. That's not C. That shouldn't be C. There are a dozen languages for doing clever dynamic magical things in code. C is still fairly straightforward. Use one of the other languages instead of bagging down C with complexity until it turns into another difficult C++ variant over time.
adamrt 5y ago
> Why "on function exit" style defers - already known to be a bad idea from Go - is beyond me Is there something you can point me to about this? I write Go professionally and from a readability and utility standpoint I really like it in common scenarios. I hadn't heard its a know bad idea and am just curious. Thanks.
- kaba0 5y ago
  I think parent means that there are languages with scope-based clean-up (e.g. in rust/c++ a value will be cleaned up at the end of the scope that contained it, so one can even create a separate block inside a function) which is a better choice than forcing people to do clean up at the end of the function.
  - tialaramex 5y ago
    Note that Rust isn't dropping things "at the end of the scope" but at the end of their lifetime, it's just that if you declare local variables their lifetime ends when they fall out of scope and so this often (but not always, so it's worth remembering to care about lifetimes not scopes) coincides for values in those variables. Making things more confusing, Rust is inferring scopes you never explicitly wrote, for example Rust brings a new scope into existence whenever you declare a variable with a let statement: let good = something.iter().filter(is_good).count(); // good is a usize let good = format!("{} of them were good", good); // a String This is fairly idiomatic Rust, whereas it would sound alarm bells in a lot of languages because their shadowing is dangerous (if you hate shadowing you can tell Rust's linter to forbid this, but may find some other people's Rust hard to read so I suggest trying to see if you can live with it instead). Obviously that first variable named "good" is gone by the time there's a new variable named good, and so that usize was dropped (but, dropping a usize doesn't do anything interesting, beyond making life harder for a debugger on optimised code since this "variable" may never really exist in the machine code). On the other hand the String in that second variable named "good" has a potentially long lifetime, if it gets out of this local variable before the variable's scope ends. Because Rust is tracking ownership, it will know whether the String is still in good when that scope ends (so the String gets dropped), or whether it was moved somewhere else (e.g. a big HashMap that lives long after this stack frame). Because it tracks borrowing, it will also notice if in the former case (where the String is to be dropped) there are outstanding references to that String alive anywhere. That's prohibited, the lifetime of the String ends here, so those references are erroneous, your program has an error which will be explained with perhaps a suggestion for how to fix it.
    - 5y ago
skybrian 5y ago
It seems like you could just ban that. Defers aren't typically used within loops, so why support it?
- clysmic 5y ago
  Sure they are, if there is something that is being acquired at the start of the loop and needs to get released at the end...
  - skybrian 5y ago
    ...of the function? You could append to a slice, after setting up a defer to free everything in the slice. ...of the loop? Call a function.
    - meithecatte 5y ago
      ...or just make defer run at the end of the scope.

by lerno 5y ago

cpuguy83 5y ago

In this case you wrap the loop in an anonymous function if you need it to be cleaned up within the scope of the loop. Or move the functionality to another function.

knome 5y ago
Adding a statement that would require a dynamic allocation for every iteration of a loop is kind of insane for C. It doesn't matter what the defer does, if it's allocated in a for statement and doesn't go off until the surrounding function exits, then it's going to have to stuff tons of function pointers and parameters somewhere, presumably alloca'd onto the stack over and over. That's not C. That shouldn't be C. There are a dozen languages for doing clever dynamic magical things in code. C is still fairly straightforward. Use one of the other languages instead of bagging down C with complexity until it turns into another difficult C++ variant over time.

adamrt 5y ago

> Why "on function exit" style defers - already known to be a bad idea from Go - is beyond me Is there something you can point me to about this? I write Go professionally and from a readability and utility standpoint I really like it in common scenarios. I hadn't heard its a know bad idea and am just curious. Thanks.

kaba0 5y ago
I think parent means that there are languages with scope-based clean-up (e.g. in rust/c++ a value will be cleaned up at the end of the scope that contained it, so one can even create a separate block inside a function) which is a better choice than forcing people to do clean up at the end of the function.
- tialaramex 5y ago
  Note that Rust isn't dropping things "at the end of the scope" but at the end of their lifetime, it's just that if you declare local variables their lifetime ends when they fall out of scope and so this often (but not always, so it's worth remembering to care about lifetimes not scopes) coincides for values in those variables. Making things more confusing, Rust is inferring scopes you never explicitly wrote, for example Rust brings a new scope into existence whenever you declare a variable with a let statement: let good = something.iter().filter(is_good).count(); // good is a usize let good = format!("{} of them were good", good); // a String This is fairly idiomatic Rust, whereas it would sound alarm bells in a lot of languages because their shadowing is dangerous (if you hate shadowing you can tell Rust's linter to forbid this, but may find some other people's Rust hard to read so I suggest trying to see if you can live with it instead). Obviously that first variable named "good" is gone by the time there's a new variable named good, and so that usize was dropped (but, dropping a usize doesn't do anything interesting, beyond making life harder for a debugger on optimised code since this "variable" may never really exist in the machine code). On the other hand the String in that second variable named "good" has a potentially long lifetime, if it gets out of this local variable before the variable's scope ends. Because Rust is tracking ownership, it will know whether the String is still in good when that scope ends (so the String gets dropped), or whether it was moved somewhere else (e.g. a big HashMap that lives long after this stack frame). Because it tracks borrowing, it will also notice if in the former case (where the String is to be dropped) there are outstanding references to that String alive anywhere. That's prohibited, the lifetime of the String ends here, so those references are erroneous, your program has an error which will be explained with perhaps a suggestion for how to fix it.
  - 5y ago

skybrian 5y ago

It seems like you could just ban that. Defers aren't typically used within loops, so why support it?

clysmic 5y ago
Sure they are, if there is something that is being acquired at the start of the loop and needs to get released at the end...
- skybrian 5y ago
  ...of the function? You could append to a slice, after setting up a defer to free everything in the slice. ...of the loop? Call a function.
  - meithecatte 5y ago
    ...or just make defer run at the end of the scope.