Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C: Simple Defer, Ready to Use

gustedt.wordpress.com

Post reply on HN
Print view View original

61–70 of 157 posts

Re: C: Simple Defer, Ready to Use

#61

Post by scott_s »

Night_Thastus wrote: post #19

I really, really do not like what that could do to the readability of code if it was used liberally. It's like GOTOs, but worse, because it's not as visible. C++'s destructors feel like a better/more explicit way to handle these sorts of problems.

Look at the Linux kernel. It uses gotos for exactly this purpose, and it’s some of the cleanest C code you’ll ever read.

C++ destructors are great for this, but are not possible in C. Destructors require an object model that C does not have.

Re: C: Simple Defer, Ready to Use

#63

Post by dktoao »

cjensen wrote: post #22
webstrand wrote: post #3

Very nice, using the goto trick to perform cleanups always felt dirty to me.

I use a few strategies instead of goto: (1) For simpler cases, wrap in do {} while (0) and break from the loop (2) For multiple cleanups, use same technique combined with checks to see if the cleanup is required. E.g. if (f != null) fclose (f) (3) put the rest of the stuff in another function so that the exit code must run on the way out. In 35 years of coding C/C++, I've literally never resorted to goto. While conve…

`the do {} while (0)` block with breaks does exactly what goto does but it is so much more hacky, less flexible and harder to follow IMHO.

Re: C: Simple Defer, Ready to Use

#66

Post by armitron »

cjensen wrote: post #22
webstrand wrote: post #3

Very nice, using the goto trick to perform cleanups always felt dirty to me.

I use a few strategies instead of goto: (1) For simpler cases, wrap in do {} while (0) and break from the loop (2) For multiple cleanups, use same technique combined with checks to see if the cleanup is required. E.g. if (f != null) fclose (f) (3) put the rest of the stuff in another function so that the exit code must run on the way out. In 35 years of coding C/C++, I've literally never resorted to goto. While conve…

35 years of coding C don't amount to much if you ignore best practices. Look at the Linux kernel to learn how gotos can be used to make the code safer and improve clarity.

There's probably something wrong if a substantial project in C does NOT use gotos.

Re: C: Simple Defer, Ready to Use

#67

Post by quelsolaar »

bangaladore wrote: post #36

I'm a strong believer that if C had defer, many bugs would disappear. The number 1 issue I find myself having when switching from C++ to C is missing RAII (Main C++ way of implementing defer).

...and a we would get a host of new bugs that would be a lot harder to fix. Invisible jumps are very bad.

Re: C: Simple Defer, Ready to Use

#68

Post by accelbred »

zwieback wrote: post #49
bangaladore wrote: post #36

I'm a strong believer that if C had defer, many bugs would disappear. The number 1 issue I find myself having when switching from C++ to C is missing RAII (Main C++ way of implementing defer).

I agree about missing RAII when switching away from C++ but it seems like defer cleans up after enclosing function exits while RAII cleans up when object goes out of scope, which is more fine-grained. Maybe I'm misunderstanding exactly when defer would clean up but it seems more like a safety feature. As people pile more stuff into the function the cleanup would be deferred more and more while RAII encapsulates the m…

This defer (using attribute cleanup) as well as Zig's are run when going out of scope. Go's runs at function exit.

Re: C: Simple Defer, Ready to Use

#69

Post by quelsolaar »

accelbred wrote: post #28
Night_Thastus wrote: post #19

I really, really do not like what that could do to the readability of code if it was used liberally. It's like GOTOs, but worse, because it's not as visible. C++'s destructors feel like a better/more explicit way to handle these sorts of problems.

Destructors are hidden control flow, and can be non-obvious for structs from other files. I find they make code significantly harder to follow than in plain C. Defer does not have the problem, as all the logic in your function is explicitly there.

Not right there, some other place in the function. Also people will start adding defer in macros and then things will go sideways.
Post reply on HN