Defer available in gcc and clang

Post by sparkie » Fri, Feb 20, 2026, 4:42 PM UTC

usefulcat wrote: post #218

sparkie wrote: post #187

Earlier quoted context omitted.

Defer might be better than nothing, but it's still a poor solution. An obvious example of a better, structural solution is C#'s `using` blocks. using (var resource = acquire()) { } // implicit resource.Dispose(); While we don't have the same simplicity in C because we don't use this "disposable" pattern, we could still perhaps learn something from syntax and use a secondary block to have scoped defers. Something like…

That is a different approach, but I don't think you've demonstrated why it's better. Seems like that approach forces you to introduce a new scope for every resource, which might otherwise be unnecessary: using (var resource1 = acquire() { using (var resource2 = acquire()) { using (var resource3 = acquire()) { // use resources here.. } } } Compared to: var resource1 = acquire(); defer { release(resource1); } var resou…

    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.

    use auto res1 = acquire1() defer { free(res1); };
    use auto res2 = acquire2() defer { free(res2); };
    use auto res3 = acquire3() defer { free(res3); };
    // use resources here

Post by [deleted] » Fri, Feb 20, 2026, 5:06 PM UTC

mort96 wrote: post #171

9rx wrote: post #165

Earlier quoted context omitted.

What's the use-case for block-level defer? In a tight loop you'd want your cleanup to happen after the fact. And in, say, an IO loop, you're going to want concurrency anyway, which necessarily introduces new function scope.

> In a tight loop you'd want your cleanup to happen after the fact. Why? Doing 10 000 iterations where each iteration allocates and operates a resource, then later going through and freeing those 10 000 resources, is not better than doing 10 000 iterations where each iteration allocates a resource, operates on it, and frees it. You just waste more resources. > And in, say, an IO loop, you're going to want concurrency…

Post by mort96 » Fri, Feb 20, 2026, 5:24 PM UTC

win311fwg wrote: post #223

nasretdinov wrote: post #222

Earlier quoted context omitted.

Using a "work queue", i.e. a channel would still have a for loop like for filename := range workQueue { fp, err := os.Open(filename) if err != nil { ... } defer fp.Close() // do work } Which would have the same exact problem :)

I don't see the problem. for _, filename := range files { queue or more realistically, var group errgroup.Group group.SetLimit(10) for _, filename := range files { group.Go(func() error { f, err := os.Open(filename) if err != nil { return fmt.Errorf("failed to open file %s: %w", filename, err) } defer f.Close() // ... return nil }) } if err := group.Wait(); err != nil { return fmt.Errorf("failed to process files: %w"…

    // Spawn workers
    for _ := range 10 {
        go func() {
            for path := range workQueue {
                fp, err := os.Open(path)
                if err != nil { ... }
                defer fp.Close()
                // do work
            }
        }()
    }

    // Iterate files and give work to workers
    for _, path := range paths {
        workQueue