5 ms·

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 w

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.

laserbeam 8mo ago
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 changes in C to express errors.
- qsera 8mo ago
  >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 further and want destructors in C. Because of internet, such voices can now reach out to each other, gather and cause a change. But before, such voices would have to go through a lot of sensible heads before they would be able to reach each other. In other words, bad ideas got snuffed early before internet, but now they go mainstream easily. So you see, it starts out slow, but then more and more stuff gets added which diverges more and more from the point.
  - duckerude 8mo ago
    That comment is saying to use C++, not to add destructors to C.
  - Galanwe 8mo ago
    I get your point, though in the specific case of defer, looks like we both agree it's really a good move. No more spaghetti of goto err_*; in complex initialization functions.
    - qsera 8mo ago
      >we both agree it's really a good move Actually I am not sure I do. It seems to me that even though `defer` is more explicit than destructors, it still falls under "spooky action at a distance" category.
      - Galanwe 8mo ago
        I don't understand why destructors enter the discussion. This is C, there is no destructors. Are you comparing "adding destructors to C" vs "adding defer to C"? The former would be bring so much in C that it wouldn't be C anymore. And if your point is "you should switch to C++ to get destructors", then it seems out of topic. By very definition, if we're talking about language X and your answer is "switch to Y", this is an entirely different subject, of very few interest to people programming in X.
        qsera 8mo ago
        Sorry, I had some other thread that involved destructors in my head. But the point is `defer` is still in "spooky action at a distance" category that I generally don't want in programming languages, especially in c.
        Galanwe 8mo ago
        > `defer` is still in "spooky action at a distance" category Agree, this is also why I'm a bit weary of it. What brings me on the "pro" side is that, defer or not defer, there will need to be some kind of cleanup anyway. It's just a matter of where it is declared, and close to the acquisition is arguably better. The caveat IMHO is that if a codebase is not consistent in its use, it could be worst.
        8mo ago
  - ubercore 8mo ago
    Modern Python is great :shrug:
majke 8mo ago
Not necessarily. In classic C we often build complex state machines to handle errors - especially when there are many things that need to be initialized (malloced) one after another and each might fail. Think the infamous "goto error". I think defer{} can simplify these flows sometimes, so it can indeed be useful for good old style C.
Mond_ 8mo ago
I think a lot of the really old school people don't care, but a lot of the younger people (especially those disillusioned with C++ and not fully enamored with Rust) are in fact quite happy for C to evolve and improve in conservative, simple ways (such as this one).
lich_king 8mo ago
> I still stay with C89 because I know it will be portable anywhere With respect, that sounds a bit nuts. It's been 37 years since C89; unless you're targeting computers that still have floppy drives, why give up on so many convenience features? Binary prefixes (0b), #embed, defined-width integer types, more flexibility with placing labels, static_assert for compile-time sanity checks, inline functions, declarations wherever you want, complex number support, designated initializers, countless other things that make code easier to write and to read. Defer falls in roughly the same category. It doesn't add a whole lot of complexity, it's just a small convenience feature that doesn't add any runtime overhead.
- robinsonb5 8mo ago
  To be honest I have similar reservations. The one huge advantage of C is its ubiquity - you can use it on the latest shiny computer / OS / compiler as well as some obscure embedded platform with a compiler that hasn't been updated since 2002. (That's a rare enough situation to be unimportant, right? /laughs in industrial control gear.) I'm wary of anything which fragments the language and makes it inaccessible to subsections of its traditional strongholds. While I'm not a huge fan of the "just use Rust" attitude that crops up so often these days, you could certainly make an argument that if you want modern language features you should be using a more modern language. (And, for the record, I do still write software - albeit recreationally - for computers that have floppy drives.)
  - uecker 8mo ago
    C has its unique advantages that make some of us prefer it to C++ or Rust or other languages. But it also has some issues that can be addressed. IMHO it should evolve, but very slowly. C89 is certainly a much worse language than C99 and I think most of the changes in C23 were good. It is fine to not use them for the next two decades, but I think it is good that most projects moved on from C89 so it is also good that C99 exists even though it took a long time to be adopted. And the same will be true for C23 in the future.
    - throwaway17_17 8mo ago
flohofwoe 8mo ago
> still stay with C89 You're missing out on one of the best-integrated and useful features that have been added to a language as an afterthought (C99 designated initialization). Even many moden languages (e.g. Rust, Zig, C++20) don't get close when it comes to data initialization.
- masklinn 8mo ago
  Just straight up huffing paint are we.
  - flohofwoe 8mo ago
    Explain why? Have you used C99 designated init vs other languages? E.g. neither Rust, Zig nor C++20 can do this: https://github.com/floooh/sokol-samples/blob/51f5a694f61425319568982a21b0916bd33f9f71/sapp/texcube-sapp.c#L124-L140 https://github.com/floooh/sokol-samples/blob/51f5a694f614253... Odin gets really close but can't chain initializers (which is ok though): https://github.com/floooh/sokol-odin/blob/d0c98fff9631946c117f5d853babea057bc76de1/examples/texcube/main.odin#L117-L132 https://github.com/floooh/sokol-odin/blob/d0c98fff9631946c11...
    - phicoh 8mo ago
      In general it would help if you would spend some text on describing what features of C99 are missing in other languages. Giving some code and assume that the reader will figure it out is not very effective. As far as I can tell, Rust can do what it is in your example (which different syntax of course) except for this particular way of initializing an array. To me, that seems like a pretty minor syntax issue to that could be added to Rust if there would be a lot of demand for initializing arrays this way.
      - flohofwoe 8mo ago
        I can show more code examples instead: E.g. notice how here in Rust each nested struct needs a type annotation, even though the compiler could trivially infer the type. Rust also cannot initialize arrays with random access directly, it needs to go through an expression block. Finally Rust requires `..Default::default()`: https://github.com/floooh/sokol-rust/blob/f824cd740d2ac96691cebef2d7ee761077e5c382/examples/texcube/texcube.rs#L128-L150 https://github.com/floooh/sokol-rust/blob/f824cd740d2ac96691... Zig has most of the same issues as Rust, but at least the compiler is able to infer the nested struct types via `.{ }`: https://github.com/floooh/sokol-zig/blob/17beeab59a64b12c307a07a9a674cee563fd5835/examples/texcube.zig#L115-L130 https://github.com/floooh/sokol-zig/blob/17beeab59a64b12c307... I don't have C++ code around, but compared to C99 it has the following restrictions: - designators must appear in order (a no-go for any non-trivial struct) - cannot chain designators (e.g. `.a.b.c = 123`) - doesn't have the random array access syntax via `[index]` > ...like a pretty minor syntax issue... ...sure, each language only has a handful minor syntax issues, but these papercuts add up to a lot of syntax noise to sift through when compared to the equivalent C99 code.
rwmj 8mo ago
That ship has sailed. Lots of open source C projects already use attribute((cleanup)) (which is the same thing).
ozgrakkurt 8mo ago
Isn’t goto cleanup label good enough anyway? Goto approach also covers some more complicated cases
pjmlp 8mo ago
Then why not even better, K&R C with external assembler, that is top. /s
- Am4TIfIsER0ppos 8mo ago
  > external assembler Is that supposed to exacerbate how poor that choice is. External assembly is great.
  - pjmlp 8mo ago
    When talking about K&R C and the assembler provided by UNIX System V, yes. Even today, the only usable Assemblers on UNIX platforms were born in PC or Amiga.
mort96 8mo ago
Defer is a very simple feature where all code is still clearly visible and nothing is called behind your back. I write a lot of C++, and it's a vastly more complex language than "C with defer". Defer is so natural to C that all compilers have relatively broadly non-standard ways of mimicking it (e.g __attribute__((cleanup)). If you want to write C++, write C++. If you want to write C, but want resource cleanup to be a bit nicer and more standard than __attribute__((cleanup)), use C with defer. The two are not comparable.

laserbeam 8mo ago

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 changes in C to express errors.

qsera 8mo ago
>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 further and want destructors in C. Because of internet, such voices can now reach out to each other, gather and cause a change. But before, such voices would have to go through a lot of sensible heads before they would be able to reach each other. In other words, bad ideas got snuffed early before internet, but now they go mainstream easily. So you see, it starts out slow, but then more and more stuff gets added which diverges more and more from the point.
- duckerude 8mo ago
  That comment is saying to use C++, not to add destructors to C.
- Galanwe 8mo ago
  I get your point, though in the specific case of defer, looks like we both agree it's really a good move. No more spaghetti of goto err_*; in complex initialization functions.
  - qsera 8mo ago
    >we both agree it's really a good move Actually I am not sure I do. It seems to me that even though `defer` is more explicit than destructors, it still falls under "spooky action at a distance" category.
    - Galanwe 8mo ago
      I don't understand why destructors enter the discussion. This is C, there is no destructors. Are you comparing "adding destructors to C" vs "adding defer to C"? The former would be bring so much in C that it wouldn't be C anymore. And if your point is "you should switch to C++ to get destructors", then it seems out of topic. By very definition, if we're talking about language X and your answer is "switch to Y", this is an entirely different subject, of very few interest to people programming in X.
      - qsera 8mo ago
        Sorry, I had some other thread that involved destructors in my head. But the point is `defer` is still in "spooky action at a distance" category that I generally don't want in programming languages, especially in c.
        Galanwe 8mo ago
        > `defer` is still in "spooky action at a distance" category Agree, this is also why I'm a bit weary of it. What brings me on the "pro" side is that, defer or not defer, there will need to be some kind of cleanup anyway. It's just a matter of where it is declared, and close to the acquisition is arguably better. The caveat IMHO is that if a codebase is not consistent in its use, it could be worst.
        8mo ago
- ubercore 8mo ago
  Modern Python is great :shrug:

majke 8mo ago

Not necessarily. In classic C we often build complex state machines to handle errors - especially when there are many things that need to be initialized (malloced) one after another and each might fail. Think the infamous "goto error". I think defer{} can simplify these flows sometimes, so it can indeed be useful for good old style C.

Mond_ 8mo ago

I think a lot of the really old school people don't care, but a lot of the younger people (especially those disillusioned with C++ and not fully enamored with Rust) are in fact quite happy for C to evolve and improve in conservative, simple ways (such as this one).

lich_king 8mo ago

> I still stay with C89 because I know it will be portable anywhere With respect, that sounds a bit nuts. It's been 37 years since C89; unless you're targeting computers that still have floppy drives, why give up on so many convenience features? Binary prefixes (0b), #embed, defined-width integer types, more flexibility with placing labels, static_assert for compile-time sanity checks, inline functions, declarations wherever you want, complex number support, designated initializers, countless other things that make code easier to write and to read. Defer falls in roughly the same category. It doesn't add a whole lot of complexity, it's just a small convenience feature that doesn't add any runtime overhead.

robinsonb5 8mo ago
To be honest I have similar reservations. The one huge advantage of C is its ubiquity - you can use it on the latest shiny computer / OS / compiler as well as some obscure embedded platform with a compiler that hasn't been updated since 2002. (That's a rare enough situation to be unimportant, right? /laughs in industrial control gear.) I'm wary of anything which fragments the language and makes it inaccessible to subsections of its traditional strongholds. While I'm not a huge fan of the "just use Rust" attitude that crops up so often these days, you could certainly make an argument that if you want modern language features you should be using a more modern language. (And, for the record, I do still write software - albeit recreationally - for computers that have floppy drives.)
- uecker 8mo ago
  C has its unique advantages that make some of us prefer it to C++ or Rust or other languages. But it also has some issues that can be addressed. IMHO it should evolve, but very slowly. C89 is certainly a much worse language than C99 and I think most of the changes in C23 were good. It is fine to not use them for the next two decades, but I think it is good that most projects moved on from C89 so it is also good that C99 exists even though it took a long time to be adopted. And the same will be true for C23 in the future.
  - throwaway17_17 8mo ago

flohofwoe 8mo ago

> still stay with C89 You're missing out on one of the best-integrated and useful features that have been added to a language as an afterthought (C99 designated initialization). Even many moden languages (e.g. Rust, Zig, C++20) don't get close when it comes to data initialization.

masklinn 8mo ago
Just straight up huffing paint are we.
- flohofwoe 8mo ago
  Explain why? Have you used C99 designated init vs other languages? E.g. neither Rust, Zig nor C++20 can do this: https://github.com/floooh/sokol-samples/blob/51f5a694f61425319568982a21b0916bd33f9f71/sapp/texcube-sapp.c#L124-L140 https://github.com/floooh/sokol-samples/blob/51f5a694f614253... Odin gets really close but can't chain initializers (which is ok though): https://github.com/floooh/sokol-odin/blob/d0c98fff9631946c117f5d853babea057bc76de1/examples/texcube/main.odin#L117-L132 https://github.com/floooh/sokol-odin/blob/d0c98fff9631946c11...
  - phicoh 8mo ago
    In general it would help if you would spend some text on describing what features of C99 are missing in other languages. Giving some code and assume that the reader will figure it out is not very effective. As far as I can tell, Rust can do what it is in your example (which different syntax of course) except for this particular way of initializing an array. To me, that seems like a pretty minor syntax issue to that could be added to Rust if there would be a lot of demand for initializing arrays this way.
    - flohofwoe 8mo ago
      I can show more code examples instead: E.g. notice how here in Rust each nested struct needs a type annotation, even though the compiler could trivially infer the type. Rust also cannot initialize arrays with random access directly, it needs to go through an expression block. Finally Rust requires `..Default::default()`: https://github.com/floooh/sokol-rust/blob/f824cd740d2ac96691cebef2d7ee761077e5c382/examples/texcube/texcube.rs#L128-L150 https://github.com/floooh/sokol-rust/blob/f824cd740d2ac96691... Zig has most of the same issues as Rust, but at least the compiler is able to infer the nested struct types via `.{ }`: https://github.com/floooh/sokol-zig/blob/17beeab59a64b12c307a07a9a674cee563fd5835/examples/texcube.zig#L115-L130 https://github.com/floooh/sokol-zig/blob/17beeab59a64b12c307... I don't have C++ code around, but compared to C99 it has the following restrictions: - designators must appear in order (a no-go for any non-trivial struct) - cannot chain designators (e.g. `.a.b.c = 123`) - doesn't have the random array access syntax via `[index]` > ...like a pretty minor syntax issue... ...sure, each language only has a handful minor syntax issues, but these papercuts add up to a lot of syntax noise to sift through when compared to the equivalent C99 code.

rwmj 8mo ago

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

ozgrakkurt 8mo ago

Isn’t goto cleanup label good enough anyway? Goto approach also covers some more complicated cases

pjmlp 8mo ago

Then why not even better, K&R C with external assembler, that is top. /s

Am4TIfIsER0ppos 8mo ago
> external assembler Is that supposed to exacerbate how poor that choice is. External assembly is great.
- pjmlp 8mo ago
  When talking about K&R C and the assembler provided by UNIX System V, yes. Even today, the only usable Assemblers on UNIX platforms were born in PC or Amiga.

mort96 8mo ago

Defer is a very simple feature where all code is still clearly visible and nothing is called behind your back. I write a lot of C++, and it's a vastly more complex language than "C with defer". Defer is so natural to C that all compilers have relatively broadly non-standard ways of mimicking it (e.g __attribute__((cleanup)). If you want to write C++, write C++. If you want to write C, but want resource cleanup to be a bit nicer and more standard than __attribute__((cleanup)), use C with defer. The two are not comparable.