Can somebody explain why this is significantly better than using goto pattern?
Genuinely curious as I only have a small amount of experience with c and found goto to be ok so far
Genuinely curious as I only have a small amount of experience with c and found goto to be ok so far
In any case, the biggest advantage IMO is that resource acquisition and cleanup are next to each other. My brain understands the code better when I see "this is how the resource is acquired, this is how the resource will be freed later" next to each other, than when it sees "this is how this resource is acquired" on its own or "this is how the resource is freed" on its own. When writing, I can write the acquisition and the free at the same time in the same place, making me very unlikely to forget to free something.
Lovely fairy tale. Now can you tell me how you love to scroll back and examine all the defer blocks within a scope when it ends to understand what happens at that point?
using (var resource = acquire()) {
} // implicit resource.Dispose();
using (auto resource = acquire(); free(resource)) {
} // free(resource) call inserted here.
for (auto it = 0; it < count; it++) {
} // automatically inserts it++; it < count; and conditional branch after secondary block of for loop.
#define using(var, acquire, release) \
auto var = (acquire); \
for (bool var##_once = true; var##_once; var##_once = false, (release))
using (foo, malloc(szfoo), free(foo)) {
using (bar, malloc(szbar), free(bar)) {
...
} // free(bar) gets called here.
} // free(foo) gets called here. using (var resource1 = acquire() {
using (var resource2 = acquire()) {
using (var resource3 = acquire()) {
// use resources here..
}
}
}
var resource1 = acquire();
defer { release(resource1); }
var resource2 = acquire();
defer { release(resource2); }
var resource3 = acquire();
defer { release(resource3); }
// use resources here
using (auto res1 = acquire1(); free(res1))
using (auto res2 = acquire2(); free(res2))
using (auto res3 = acquire3(); free(res3))
{
// use resources here
}
// free(res3); free(res2); free(res1); called in that order.
---
Even if we didn't want to introduce new scope, we could have something like F#'s `use`[1], which makes the resource available until the end of the scope it was introduced.
use auto res1 = acquire1() defer { free(res1); };
use auto res2 = acquire2() defer { free(res2); };
use auto res3 = acquire3() defer { free(res3); };
// use resources here
[1]:https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
But it adds a new dimension of control flow, which in a garbage collected language like Go is less worrisome whereas in C this can create new headaches in doing things in the right order. I don't think it will eliminate goto error handling for complex cases.
But people know it from other languages, and seem to like it, so I guess it is good to have it also in C.
http://robertseacord.com/wp/2020/09/10/adding-a-defer-mechan...
Cleanup is good. Jumping around with "goto" confused most people in practice. It seems highly likely that most programmers model "defer" differently in their minds.
EDIT:
IIRC it was CVE-2025-26465. Read the code and the patch.
With "goto" the cleanup-up can jump anywhere. With "defer" the cleanup cannot really jump anywhere. It is easier to mentally stick to simply cleaning up in a common sense way. And taking care of multiple "unrelated" clean-up steps is "handled for you."
(Attacks on this sometimes approach complaints about lack of "common sense".)
2. Defer is mostly useful for C++ code that needs to interact with C API because these two are fundamentally different. C API usually exposes functions "create_something" and "destroy_something", while the C++ pattern is to have an object that has "create_something" hidden inside its constructor, and "destroy_something" inside its destructor.
For example if I have a ffi function that transfers the ownership of some allocator in the middle of the function.