4 ms·
> The C standards committee doesn't really know what to do with the language it seems. Honest question: why should C change? I mean, if all we want is access t
by fivea 5y ago
> The C standards committee doesn't really know what to do with the language it seems.
Honest question: why should C change? I mean, if all we want is access to higher-level core language features not provided by C, isn't it better to just pick up a higher-level language that already offers it? After all, if you add higher level features like smart pointers, is it really worth it to keep other features like the extensive reliance on the C preprocessor, dangerous string handling, and a spartan and in some cases outright unsafe standard library? Or would it be better to cut our losses and just adopt languages that already fixed those issues?
- e-dant 5y agoHonest answer: of course it is, and no serious developer is arguing otherwise. I just finished shipping an industrial lighting unit for “smart farms.” I worked extensively on embedded hardware. The most advanced processor I used was armv6, with the majority of hardware being IC or FPGA. I used C for one thing only: reading the bitstream from microcontrollers into memory. After which point, I used c++ (17) with exclusively standard libraries (one exception: boost’s ASIO for http) to implement any and all other features. I would have happily used c++ to read those bitstreams, but the code was so unsafe that it refused to compile. Turns out that reading raw bytes from an irregular file descriptor is so arcane and bizarre that no sane modern compiler felt good enough about itself to allow me to compile it. All that said, I would only ever allow myself to write in C in that isolated case and for that isolated purpose. Every other nanosecond of my codebase runs on modern c++. Honest answer, there is no legitimate reason to use C. If in some edge case you must, there is no legitimate reason to use it for anything other than that.
- sirwhinesalot 5y agoBut is is changing, the standards committee keeps adding things. Some of those are reasonable (stdbool.h, atomics), others are head scratchers (VLAs, now deprecated). It might have been better for C to have stayed frozen in time. But look how many libraries are written in C, such that they can be made available everywhere. Look at how many are written in C++/Rust but with C wrappers with plenty of pointers and bad error handling. Any improvements to the C standard would have meant a safer surface area for those languages to use to talk to other languages, since C is the english of programming. There's no reason why C couldn't have namespacing, out-of-band errors, fat pointers, minimal reflection (typeof), standardized attributes, etc. ages ago. None of that would have screwed with the ABI or with optimization, but would have made language interoperability a lot easier.
- fivea 5y ago> But is is changing No, not really. At least in practical terms. C11 saw some changes, and arguably only minor ones. C17 is a bugfix update to C11. And C20 is still in the works, and none of the proposed changes are relevant. Consequently, C as been dormant since the release of C99, which already was criticized for not bringing anything new to the table other than C++98 tuneups, and support for inline comments (?!)
- sirwhinesalot 5y agoC11 had some very good updates for multithreading, unicode support and alignment specifications. All of those things made the language better. Yes compared to the crazy changes going on in C++ land all of these are minor, but they are good maintenance improvements. C11 also had _Generic as a "major" addition (and a crappy one IMO). I agree that if C is not going to evolve in any meaningful way, they should probably just stop adding stuff to it entirely. Either go for a "C++11" or let it be frozen in place.