C99, C11, C17, With C23 On The Horizon. The Only Thing Stagnant On ...

Trang chủ » C99 Vs C11 Vs C17 » C99, C11, C17, With C23 On The Horizon. The Only Thing Stagnant On ...

Có thể bạn quan tâm

Hacker News new | past | comments | ask | show | jobs | submit login
pjmlp on Nov 3, 2021 | parent | context | favorite | on: Zig monthly, October 2021: Games, gamedev, Elixir,... C99, C11, C17, with C23 on the horizon.

The only thing stagnant on WG14 is their regard towards providing safer string, vector types and enumerations.

kaba0 on Nov 3, 2021 [–] Would you mind mentioning any noticeable improvements in those versions? Because C seems to remain the exact same for decades now. I only know of _Generic thingy which is hardly ever used and maybe variable length arrays?

flohofwoe on Nov 3, 2021 | parent [–] C only adding a few new features only once every few decades or so is actually a feature, not a problem (IMHO of course). C99 was the last big release, while C11 and C17 were mostly minor course corrections and spec cleanup (VLAs have been degraded to 'optional' for instance, which makes a lot of sense, because it shouldn't have gone into the standard in the first place). So far, C23 seems like a bigger release again though.

kaba0 on Nov 3, 2021 | root | parent [–] With no ill intent, could you please tell me why would anyone start a new program in C? I am seriously interested in that.

It of course has to remain with us due to the insane amount of code already written with it and some tooling (and eg for verification certain subsets of C), but it is not any closer to metal than other system programming languages, the “standard lib” is full of foot guns, it has a very weak type system, it has no way of enforcing basically anything. Also, due to the its lack of expressivity it relies on text-based macros (and those I hate with a passion, as there is hardly anything worse than text-replacing source code with no knowledge of syntactic elements).

jstimpfle on Nov 3, 2021 | root | parent | next [–] Languages are taken way too seriously, and there are way too many bad languages out there that try to dictate the shape of your solutions in a certain way. A good language shouldn't do that in my opinion, except for boring and "solved" problems. The problem with languages is (apart from LISP maybe) that you can't abstract over their syntax - so while languages should give you useful building blocks to implement a solution, they should stay out of your way as much as possible.

To me, C is the easiest way to interface with the platforms that I develop for. It's also totally sufficient to implement the ideas that I'm working on - figuring out the data layout, the flow of code and data... It offers a concise syntax for the frequent operations - load / store, arithmetic, dereferences, and function calls. Most languages are already disqualified by not offering or discouraging nesting of data types a.k.a value types, making it way too complicated to simply copy data "anonymously", using memcpy() or similar.

Think about that - the language that people can't stop bitching about because it doesn't offer "generics" is actually the one that allows you to read and write data generically without a tremendous amount of complexity and/or slowness.

That's why my personal route is to learn ways to not need the type based polymorphism offered by more complicated languages, and to get along with just straight code that can push _any_ data payload (type) to the next endpoint - without requiring the multiplication of junk in the type system and/or in the compiled binary.

Macros aren't used that much but they would be missed a lot if they weren't there to help in some cases where we need to hack an abstraction over (lexical) syntax instead of data. I said above that you can't abstract over languages' syntax, and C macros don't really do that... They're a hack, and sometimes tremendously useful.

flohofwoe on Nov 3, 2021 | root | parent | prev | next [–] Good question, I wrote about my own reasons for moving back to C from C++ a while ago:

https://floooh.github.io/2018/06/02/one-year-of-c.html

...and "modern C" is often misunderstood by C++ people who only know the fork of C known as the "common C/C++ subset" (which is basically an outdated, non-standard dialect of C that's stuck in the mid-90s):

https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.h...

However, I'm hoping to eventually abandon C in favour of Zig within the next 10 years or so :)

nrclark on Nov 4, 2021 | root | parent | prev | next [–] I've written a few CLI utilities in C over the past couple of years. Here's why I keep choosing it for tools that I want to distribute.

C is the lowest common denominator. It has good compilers that just work, with no drama or surprises. It's portable across CPUs and operating systems. It will continue to work for all Unix-like platforms long after trendier alternatives have turned to dust.

It has good code formatters and analyzers. It's an easy language to completely understand, and it's easy to read if I don't try to get to clever with macros or type tricks.

I don't have to remember whether ${language_feature} is Considered Harmful yet, like C++ or Rust where the current best practices constantly become Bad Code in favor of the next trendy feature.

The C ABI is the standard for libraries on Unix-likes, and I usually want to use a couple of special-purpose libraries. Calling libraries requires no wrappers, FFIs, or anything else.

Yes, C has limitations. Lots of them. But it also has an enduring momentum that's not going away any time soon.

rackjack on Nov 3, 2021 | root | parent | prev | next [–] C is a very simple language. I think Zig will get close to replacing it, but it also happens to be more complex, so I'm sure some people who really prefer simplicity will still use Zig.

curtain on Nov 3, 2021 | root | parent | next [–] will still use C*.

rackjack on Nov 4, 2021 | root | parent | next [–] Whoops, thanks for catching that, though the edit window's passed.

FpUser on Nov 3, 2021 | root | parent | prev [–] >"why would anyone start a new program in C"

I wrote a firmware recently for low power microcontroller. No memory allocations in code. The language is simple and easy to read unless one is purposely trying to be fancy. It is very performant - the end result and compile steps as well. And there are megatons of C libs for microcontrollers. Would not dream of using anything else for this particular task

pjmlp on Nov 4, 2021 | root | parent [–] Which is why it would be good if WG14 was a bit more security conscious.

FpUser on Nov 4, 2021 | root | parent [–] I am a practical man. The last thing I worried about is a security issues with my code on that specific device. Or should I say non issues since it works like a charm and I just can't see how C "insecurity" can bring any problems to my particular situation.

Sure let WG invest their efforts where needed but for my own case I do not care.

pjmlp on Nov 4, 2021 | root | parent [–] Until liability and lawsuits due to security exploits become a common thing.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact Search:

Từ khóa » C99 Vs C11 Vs C17