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

Defer available in gcc and clang

gustedt.wordpress.com

Post reply on HN
Print view View original

51–60 of 262 posts

Re: Defer available in gcc and clang

#51

Post by flohofwoe »

mathisfun123 wrote: post #9
Panzerschrek wrote: post #6

Such addition is great. But there is something even better - destructors in C++. Anyone who writes C should consider using C++ instead, where destructors provide a more convenient way for resources freeing.

i write C++ every day (i actually like it...) but absolutely no one is going to switch from C to C++ just for dtors.

> but absolutely no one is going to switch from C to C++ just for dtors

The decision would be easier if the C subset in C++ would be compatible with modern C standards instead of being a non-standard dialect of C stuck in ca. 1995.

Re: Defer available in gcc and clang

#52

Post by rwmj »

userbinator wrote: post #10

As others have commented already: if you want to use C++, use C++. I suspect the majority of C programmers neither care nor want stuff like this; I still stay with C89 because I know it will be portable anywhere, and complexities like this are completely at odds with the reason to use C in the first place.

That ship has sailed. Lots of open source C projects already use attribute((cleanup)) (which is the same thing).

Re: Defer available in gcc and clang

#53

Post by uecker »

thayne wrote: post #46
uecker wrote: post #36

Earlier quoted context omitted.

IMHO, it is in the best interest of your students to teach them standard C first.

There is a technical specification, so hopefully it will be standard C in the next version. And given that gcc and clang already have implementatians (and gcc has had a way to do it for a long time, although the syntax is quite different).

It is not yet a technical specification, just a draft for one, but this will hopefully change this year, and the defer patch has not been merged into GCC yet. So I guess it will become part of C at some point if experience with it is good, but at this time it is an extension.

Re: Defer available in gcc and clang

#54

Post by ubercore »

qsera wrote: post #18
laserbeam wrote: post #14

Earlier quoted context omitted.

I would say the complexity of implementing defer yourself is a bit annoying for C. However defer itself, as a language feature in a C standard is pretty reasonable. It’s a very straightforward concept and fits well within the scope of C, just as it fit within the scope of zig. As long as it’s the zig defer, not the golang one… I would not introduce zig’s errdeferr though. That one would need additional semantics chan…

>pretty reasonable It starts out small. Then before you know the language is total shit. Python is a good example. I am observing a very distinguishable phenomenon when internet makes very shallow ideas mainstream and ruin many many good things that stood the test of time. I am not saying this is one of those instances, but what the parent comment makes sense to me. You can see another comment who now wants to go fur…

Modern Python is great :shrug:

Re: Defer available in gcc and clang

#55

Post by anilakar »

LexiMax wrote: post #4

A long overdue feature. Though I do wonder what the chances are that the C subset of C++ will ever add this feature. I use my own homespun "scope exit" which runs a lambda in a destructor quite a bit, but every time I use it I wish I could just "defer" instead.

Various macro tricks have existed for a long time but nobody has been able to wrap the return statement yet. The lack of RAII-style automatic cleanups was one of the root causes for the legendary goto fail;[1] bug.

[1] https://gotofail.com/

Re: Defer available in gcc and clang

#56

Post by maccard »

flakes wrote: post #31
jonhohle wrote: post #7

It’s pedantic, but in the malloc example, I’d put the defer immediately after the assignment. This makes it very obvious that the defer/free goes along with the allocation. It would run regardless of if malloc succeeded or failed, but calling free on a NULL pointer is safe (defined to no-op in the C-spec).

I'd say a lot of users are going to borrow patterns from Go, where you'd typically check the error first. resource, err := newResource() if err != nil { return err } defer resource.Close() IMO this pattern makes more sense, as calling exit behavior in most cases won't make sense unless you have acquired the resource in the first place. free may accept a NULL pointer, but it also doesn't need to be called with one eit…

This example is exactly why RAII is the solution to this problem and not defer.

Re: Defer available in gcc and clang

#57

Post by ozgrakkurt »

userbinator wrote: post #10

As others have commented already: if you want to use C++, use C++. I suspect the majority of C programmers neither care nor want stuff like this; I still stay with C89 because I know it will be portable anywhere, and complexities like this are completely at odds with the reason to use C in the first place.

Isn’t goto cleanup label good enough anyway?

Goto approach also covers some more complicated cases

Re: Defer available in gcc and clang

#58

Post by fuhsnn »

cmovq wrote: post #29

Would defer be considered hidden control flow? I guess it’s not so hidden since it’s within the same function unlike destructors, exceptions, longjmp.

It's one of the most commonly adopted feature among C successor languages (D, Zig, Odin, C3, Hare, Jai); given how opinionated some of them are on these topics, I think it's safe to say it's generally well regarded in PL communities.

Re: Defer available in gcc and clang

#60

Post by fauigerzigerk »

L-4 wrote: post #43
kjgkjhfkjf wrote: post #2

The article is a bit dense, but what it's announcing is effectively golang's `defer` (with extra braces) or a limited form of C++'s RAII (with much less boilerplate). Both RAII and `defer` have proven to be highly useful in real-world code. This seems like a good addition to the C language that I hope makes it into the standard.

Both defer and RAII have proven to be useful, but RAII has also proven to be quite harmful in cases, in the limit introducing a lot of hidden control flow. I think that defer is actually limited in ways that are good - I don't see it introducing surprising control flow in the same way.

But of course what you call "surprising" and "hidden" is also RAII's strength.

It allows library authors to take responsibility for cleaning up resources in exactly one place rather than forcing library users to insert a defer call in every single place the library is used.

Post reply on HN