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

241–248 of 248 posts

Re: A Defer Mechanism for C

#241

Post by Dr_Emann »

ludocode wrote: post #226
Dr_Emann wrote: post #225

Earlier quoted context omitted.

Of course. There should never be more than one way to do something in c, even if it makes things easier or less error prone. This is why the -> operator would never be included in c. You can already use (*x).y, it would be SILLY to introduce a whole operator which isn't orthogonal to all existing features of the language.

I never said C's language features are orthogonal. I said they should be. C is far from a perfect language, as your example shows. Look at it from the opposite direction: if x->y didn't exist today, and the billions of lines of existing C code all used (*x).y, would you support a proposal to add a new x->y operator to the language? I doubt it.

I would absolutely support something to replace ((((a).b).c).d).e with a->b->c->d->e, regardless of how much code had been written without that feature.

Do you not like the array subscript operator, either, since a[b] can be *(a+b)? How about a && b, you can replace that with (!!a) & (!!b), with an extra 'if' if you need the short circuiting.

Re: A Defer Mechanism for C

#242

Post by _8ljf »

_8ljf wrote: post #160
dang wrote: post #153

Earlier quoted context omitted.

We detached this comment from https://news.ycombinator.com/item?id=25420221 . Please don't post shallow or snarky comments to HN [1]. It is particularly damaging when talking to a genuine expert [2]. Having a user like rseacord commenting in threads like this is great for everybody. When you incentivize them to leave, you harm the entire community. Your other comment [3] was pretty insulting too (at the beginning); p…

Honestly mate, just go ahead and delete my account.

Still here. Delete my account.

Re: A Defer Mechanism for C

#243

Post by gpderetta »

drsozesakamoto wrote: post #233
gpderetta wrote: post #87

Earlier quoted context omitted.

subroutine calls requires implicit allocation and deallocation of stack frames. Real Programmers™ use goto and manage the stack by hand.

> subroutine calls requires implicit allocation and deallocation of stack frames. Real Programmers™ use goto and manage the stack by hand. Could u point to an example of programmers doing this ?

sorry, I had forgotten the /sarcasm tag.

Although I guess Cheney on the MTA counts.( https://dl.acm.org/doi/10.1145/214448.214454 )

Re: A Defer Mechanism for C

#244

Post by DougBTX »

steveklabnik wrote: post #206
jcelerier wrote: post #159

Earlier quoted context omitted.

> I believe the situation is the same in C++, in the specific case of shared_ptr, which are a small part of codebases, if they are even used - for instance an immense amount of C++ GUI programs use Qt which doesn't use shared_ptr-like ownership semantics but instead a tree-of-objects model which does not have this issue. In contrast in Java / C# any object that has a reference to another is at risk.

Sure. That’s why I said “more deterministic.” But even a rare event disproves the guarantee.

Sorry, I meant that the behaviour is guaranteed, not that the destructor is guaranteed to be called. So in the Rc cycle example the guarantee is that the destructor won’t be called.

Re: A Defer Mechanism for C

#245

Post by jbboehr »

cycloptic wrote: post #150
ludocode wrote: post #64

Earlier quoted context omitted.

I would tend to agree with you. Unfortunately this proposal is for much more than just block scope cleanup. This proposal contains a specification for complete stack unwinding in C. It doesn't just specify defer, but also panic and recover, which jumps between functions and cleans up guard blocks across stack frames. It's essentially exceptions for C. This is frankly horrifying and I can't believe the C standards com…

>It's essentially exceptions for C. This is frankly horrifying and I can't believe the C standards committee is entertaining this. I can because C already includes setjmp/longjmp as an exception mechanism that gets used in plenty of real code. The problem here is that those don't unwind the stack so they would break and cause memory leaks when using defer statements.

If you're already using setjmp/longjmp I would suspect you are also already using an arena or avoiding heap allocations, so I don't know if it would specifically be a problem for memory leaks with defer.

Re: A Defer Mechanism for C

#246

Post by gustedt »

grok22 wrote: post #110
quelsolaar wrote: post #73

void * * a = NULL; while(TRUE) { a = malloc(sizeof *a); if(a == NULL) break; *a = malloc(1024); if(*a == NULL) break; if(!do_some_other_tests(a)) break; return a; } /* cleanup / if(a == NULL) return; if( a != NULL) free(*a); free(a); alt: void * * a = NULL; switch(TRUE) { defaultt : a = malloc(sizeof *a); if(a == NULL) break; *a = malloc(1024); if(*a == NULL) break; if(!do_some_other_tests(a)) break; return a; } /* c…

If the proposed implementation requires a guard clause, then it seems like it is no better than the while (TRUE) implementation above and it's not worth the support in the standard. Maybe it's a bit more structured and covers a few more use-cases, but not worth the standardization.

In the current proposal, the whole function body can act as a guarded block. So for simple cleanup strategies that are bound to functions, you wouldn't need this.

Re: A Defer Mechanism for C

#247

Post by steveklabnik »

DougBTX wrote: post #244
steveklabnik wrote: post #206

Earlier quoted context omitted.

Sure. That’s why I said “more deterministic.” But even a rare event disproves the guarantee.

Sorry, I meant that the behaviour is guaranteed, not that the destructor is guaranteed to be called. So in the Rc cycle example the guarantee is that the destructor won’t be called.

Ah, then I misunderstood you, yes. My bad!

Re: A Defer Mechanism for C

#248

Post by _8ljf »

dang wrote: post #153
hhas01 wrote: post #147

“What we are trying to accomplish…” See also: silk purse, sow’s ear.

We detached this comment from https://news.ycombinator.com/item?id=25420221 . Please don't post shallow or snarky comments to HN [1]. It is particularly damaging when talking to a genuine expert [2]. Having a user like rseacord commenting in threads like this is great for everybody. When you incentivize them to leave, you harm the entire community. Your other comment [3] was pretty insulting too (at the beginning); p…

Delete my account, please.

I do not want to have to ask again.

Post reply on HN