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

A Defer Mechanism for C

gustedt.wordpress.com

Post reply on HN
Print view View original

161–170 of 248 posts

Re: A Defer Mechanism for C

#161

Post by jcelerier »

sloyd wrote: post #149
_8ljf wrote: post #141

Earlier quoted context omitted.

“I can't believe the C standards committee is entertaining this.” Hey, standards committee’s gotta eat. 'defer'? I occasionaly use it in Swift to clean up resources; s’okay there, I guess, though I’m not convinced it’s better than Python’s 'with' block. But in C? One of C’s few distinguishing strengths is that the language is relatively† small and stable, and well understood. For that kind of cleanup there is already…

I couldn't agree more and created an account just to second your thoughts. This is exactly why everyone hates using modern C++. Their standards committee has run amok with every fancy feature that every new language comes out with in the past two decades. And what has that wrought? A huge language that no one fully understands and is hard to read unless you happen to be the guy that wrote it and time since writing C…

> This is exactly why everyone hates using modern C++.

speak for youreself ?

> Their standards committee has run amok with every fancy feature that every new language comes out with in the past two decades. And what has that wrought?

given the amount of languages that reimplement C++ features (and sometimes have to be dragged by the feet to get them, e.g. generics and interface methods in java), I'd say that people who don't understand c++ are doomed to reinvent it :)

Re: A Defer Mechanism for C

#162

Post by jcelerier »

loup-vaillant wrote: post #104
apples_oranges wrote: post #25

When I first saw defer I thought I'd use it much more. With Rx-type programming it's kind of even more obsolete no?

What's "Rx-type programming"?

defining flow graphs in code, see examples here: https://github.com/ReactiveX/RxJava

Re: A Defer Mechanism for C

#163

Post by saagarjha »

drran wrote: post #152

My version of defer() for C is just one line. https://github.com/vlisivka/crust/blob/master/crust-mem.h#L3... (Warning: GPL3) I switched to Rust and lost interest in C.

You can't really claim a license on one line of code that shows off a GCC extension :P

Re: A Defer Mechanism for C

#164

Post by saagarjha »

gpderetta wrote: post #83
yason wrote: post #54

Earlier quoted context omitted.

RAII is a special case of defer, due to how it abuses constructors and destructors to hook into the points of entering and exiting scope. You could write a RAII implementation in terms of defer but not the other way around. RAII doesn't help with a generic pair of init and deinit functions, such as malloc() and free() for example, unless you wrap your mallocs into "memory objects" or something. You can't do anything…

> RAII doesn't help with a generic pair of init and deinit functions, such as malloc() and free() for example, people have been writing RAII scope_exit classes for at least 20 years to do exactly this. > You can't do anything with RAII unless you wrap your stuff into objects which just forces the OO crap on everything regardless of whether it's a good fit for the OO paradigm. wrapping something in an object does not…

Well, you can only wrap objects in one, although you can "wrap" a primitive by writing lambdas for this purpose.

Re: A Defer Mechanism for C

#165

Post by kazinator »

The astonishing thing here is that there is a forum where papers on C hacks can still be considered for publication.

I some ways that is encouraging, because research in practical systems things is valuable and used to be one of the cornerstones of computer science.

Re: A Defer Mechanism for C

#168

Post by apankrat »

gpderetta wrote: post #114
apankrat wrote: post #51

Earlier quoted context omitted.

Aye, I've seen that. IMO it would've been better (read, cleaner) to merge lambdas and function pointers into a single language construct. Throw in the partial application too and we'd be have a natively supported concept of a "callable" instance - void foo(int tick); void bar(int tick, int tock); void do_something( void (* progress)(int tick) ); do_something( foo ); do_something( bar(,1) ); do_something( void (int ti…

problem is, to unify lambdas and function pointers you either break the ABI and use fat pointers or you need to disable W^X which is a security issue.

This will break the ABI indeed. That's given.

Re: A Defer Mechanism for C

#169

Post by josephcsible »

coldtea wrote: post #157
josephcsible wrote: post #116

Earlier quoted context omitted.

Goto isn't nonlocal. You know you'll only every jump from them, and that you'll only ever jump to the specified label.

The specified label is what makes goto no-local. You need to check the whole codebase to find out where you'll land. By your definition only [1] "come from" would be non-local. [1] https://en.wikipedia.org/wiki/COMEFROM

> the whole codebase

You can't goto out of a function, and you know there's exactly one such label inside it. If goto isn't local, then neither are function calls, since the function could be defined anywhere in the codebase.

Re: A Defer Mechanism for C

#170

Post by IAmADHDToo »

apankrat wrote: post #58
coldtea wrote: post #6

Earlier quoted context omitted.

> One of the key interest of C compared to more recent languages is that everything is explicit. There's nothing implicit about defer.

Every defer statement is ultimately pushing a lambda into some stack that is executed when the defer block is exited. With an exception of setjmp/longjmp, I can't think of an existing C construct with similar run-time complexity.

That's indeed tricky: if there's a for loop inside the guarded block which generates many defers, a stack would have to be created to handle them somehow.
Post reply on HN