3 ms·

I took some shit in the comments yesterday for suggesting "you can do it with a few lines of standard C++" to another similar thread, but yet again here we are.

I took some shit in the comments yesterday for suggesting "you can do it with a few lines of standard C++" to another similar thread, but yet again here we are. Defer takes 10 lines to implement in C++. [1] You don't have to wait 50 years for a committee to introduce basic convenience features, and you don't have to use non-portable extensions until they do (and in this case the __attribute__((cleanup)) has no equivalent in MSVC), if you use a remotely extensible language. [1] https://www.gingerbill.org/article/2015/08/19/defer-in-cpp/ https://www.gingerbill.org/article/2015/08/19/defer-in-cpp/

mort96 8mo ago
Why is this a relevant comment? We're talking about C, not C++. If you wanted to suggest using an alternative language, you're probably better off recommending Zig: defer takes 0 lines to implement there, and it's closer to C than what C++ is.
- nananana9 8mo ago
  Everyone reading this (you included) knows full well that unlike Zig/Rust/Odin/whatever, C++ has the special property that you can quite literally* write C code in it, AND you can implement whatever quality of life fixes you need with targeted usage of RAII+templates+macros (defer, bounds checked accesses, result types, whatever). My comment is targeted towards the programmer who is excited about features like this - you can add an extra two characters to your filename and trivially implement those improvements (and more) yourself, without any alterations to your codebase or day to day programming style.
  - mort96 8mo ago
    C in C++ is a pretty terrible experience. The differences your asterisk alludes to are actually quite significant in practice: C++ doesn't let you implicitly cast from void* to other pointer types. This breaks the way you typically heap-allocate variables in C: instead of 'mytype *foo = malloc(sizeof(*foo))', you have to write 'mytype *foo = (mytype *)malloc(sizeof(*foo))'. This adds a non-trivial amount of friction to something you do every handful of lines. String literals in C++ are 'const char *' instead of 'char *'. While this is more technically correct, it means you have to add casts to 'char *' all over the place. Plenty of C APIs are really not very ergonomic when string literals aren't 'char *'. And the big one: C++ doesn't have C's struct literals. Lots of C APIs are super ergonomic if you call them like this: some_function(&(struct params) { .some_param = 10, .other_param = 20, }); You can't do that in C++. C++ has other features (such as its own, different kind of aggregate initialization with designated initializers, and the ability for temporaries to be treated as const references) which make C++ APIs nice to work with from C++, but C APIs based around the assumption that you'll be using struct literals aren't nice to use from C++. If you wanna use C, use C. C is a much better C than C++ is.
    - nananana9 8mo ago
      I'll give you the last bullet you missed, you're also giving up the { [3] = ..., [5] = ... } array initializer syntax. I like both these syntax-es (syntacies? synticies?) and I hope they make their way to C++, but if we're honestly evaluating features -- take their utility, multiply it by 100 and in my book it's still losing out against either defer or slices/span types. If you disagree with this, then your calculus for feature utility is completely different than mine. I suspect for most people that's not the case, and most of the time the reason to pick C over C++ is ideological, not because of these 2 pieces of syntax sugar. "I like it" is a good enough reason to use something, my original comment is to the person who wants to use C but gets excited about features like this - I don't know how many of those people are aware of how trivially most of these things can be accomplished in C++.
      - mort96 8mo ago
        I write way more C++ than I write C. I was not comparing C and C++ in terms of which language is better or has more significant features. I was evaluating your suggestion to write C in C++ and get defer that way.
    - deleted 8mo ago
      [deleted]
    - BoredomIsFun 8mo ago
      > C in C++ is a pretty terrible experience No I think, it the other way around, a fantastic experience; yes, you miss certain features of C, but instead you get massive benefits of C++ - above-mentioned defer, that'd work on any moderrn C++ compiler, constexpr's, a strategic use of STL while prototyping, templates etc. > C++ doesn't let you implicitly cast from void* to other pointer types It does, but that is not a good thing IMO anyway. > Plenty of C APIs are really not very ergonomic when string literals aren't 'char '. Examples? In my experience most C libraries have const char in their signatures whenever it makes sense. > C is a much better C than C++ is. Nonsense.

mort96 8mo ago

Why is this a relevant comment? We're talking about C, not C++. If you wanted to suggest using an alternative language, you're probably better off recommending Zig: defer takes 0 lines to implement there, and it's closer to C than what C++ is.

nananana9 8mo ago
Everyone reading this (you included) knows full well that unlike Zig/Rust/Odin/whatever, C++ has the special property that you can quite literally* write C code in it, AND you can implement whatever quality of life fixes you need with targeted usage of RAII+templates+macros (defer, bounds checked accesses, result types, whatever). My comment is targeted towards the programmer who is excited about features like this - you can add an extra two characters to your filename and trivially implement those improvements (and more) yourself, without any alterations to your codebase or day to day programming style.
- mort96 8mo ago
  C in C++ is a pretty terrible experience. The differences your asterisk alludes to are actually quite significant in practice: C++ doesn't let you implicitly cast from void* to other pointer types. This breaks the way you typically heap-allocate variables in C: instead of 'mytype *foo = malloc(sizeof(*foo))', you have to write 'mytype *foo = (mytype *)malloc(sizeof(*foo))'. This adds a non-trivial amount of friction to something you do every handful of lines. String literals in C++ are 'const char *' instead of 'char *'. While this is more technically correct, it means you have to add casts to 'char *' all over the place. Plenty of C APIs are really not very ergonomic when string literals aren't 'char *'. And the big one: C++ doesn't have C's struct literals. Lots of C APIs are super ergonomic if you call them like this: some_function(&(struct params) { .some_param = 10, .other_param = 20, }); You can't do that in C++. C++ has other features (such as its own, different kind of aggregate initialization with designated initializers, and the ability for temporaries to be treated as const references) which make C++ APIs nice to work with from C++, but C APIs based around the assumption that you'll be using struct literals aren't nice to use from C++. If you wanna use C, use C. C is a much better C than C++ is.
  - nananana9 8mo ago
    I'll give you the last bullet you missed, you're also giving up the { [3] = ..., [5] = ... } array initializer syntax. I like both these syntax-es (syntacies? synticies?) and I hope they make their way to C++, but if we're honestly evaluating features -- take their utility, multiply it by 100 and in my book it's still losing out against either defer or slices/span types. If you disagree with this, then your calculus for feature utility is completely different than mine. I suspect for most people that's not the case, and most of the time the reason to pick C over C++ is ideological, not because of these 2 pieces of syntax sugar. "I like it" is a good enough reason to use something, my original comment is to the person who wants to use C but gets excited about features like this - I don't know how many of those people are aware of how trivially most of these things can be accomplished in C++.
    - mort96 8mo ago
      I write way more C++ than I write C. I was not comparing C and C++ in terms of which language is better or has more significant features. I was evaluating your suggestion to write C in C++ and get defer that way.
  - deleted 8mo ago
    [deleted]
  - BoredomIsFun 8mo ago
    > C in C++ is a pretty terrible experience No I think, it the other way around, a fantastic experience; yes, you miss certain features of C, but instead you get massive benefits of C++ - above-mentioned defer, that'd work on any moderrn C++ compiler, constexpr's, a strategic use of STL while prototyping, templates etc. > C++ doesn't let you implicitly cast from void* to other pointer types It does, but that is not a good thing IMO anyway. > Plenty of C APIs are really not very ergonomic when string literals aren't 'char '. Examples? In my experience most C libraries have const char in their signatures whenever it makes sense. > C is a much better C than C++ is. Nonsense.