101–110 of 363 posts
Earlier quoted context omitted.
The downside of reordering being performance? Or something else?
Performance is usually the upside. The downside is subtle bugs that can happen due to side effects of the statements being reordered between sequence points.
Earlier quoted context omitted.
Why does it matter if compile time is 100ms or 300ms? At even a second, that’s going to be so negligible in the context of code-compile-debug work. Especially if something like a flash download is involved.
Are your rust builds really that fast? Wth am I doing wrong! I'd love to measure it in seconds.
That said, cargo check is fast, and my general experience with Rust is that it generally works once it compiles. People getting into more advanced features might have different experiences.
I can't tell if this is serious. Surely if you're still using C now it's for legacy reasons. And if using it for legacy reasons you are likely stuck using an old C standard. So who will use C23?
We all use C because it works and we love to get things done.
Earlier quoted context omitted.
And x86, Arm, PIC, Xtensa,... and everything else.
There is where you went off rails, with greetings from ACM. https://queue.acm.org/detail.cfm?id=3212479
This is the claim which started this thread:
>>C is a portable alternative to assembly language.
Earlier quoted context omitted.
Huh? What do you think defines “regular C code that works”? Standards. Every compiler you have used operates at a bare minimum on the C standard. That’s why they are often advertised (if not GCC/Clang which are assumed to be up to date) as “C(89|99|11|17) compliant.” “Code that works” is code which is operates under constraints and guarantees specified by a standard, anything else is undefined or unportable.
Only the standards people care about standards. We (programmers) want to just get things done. We don't care about the standards. No one reads the standards. Also no one cares about portability. All computers have been the same for the last 20 years.
Earlier quoted context omitted.
C is the best choice if you want all of: small (both language and binaries), fast (both compiler and binaries), obvious (no/minimal complex magic), close to the metal, with excellent debugging support, portability and integrations. No other language has been battle tested for longer and more extensively than C. Your kernels, OSes, drivers, databases, web servers and compilers are written in C. If some of these featur…
C isn’t that small, compare it to a Zig hello world. Fast is relative — due to C not having good expressive/abstracting powers, it will leave you to inferior solutions, eg. counting string length multiple times at call sites, vs C++’s small string optimization, which is simply not possible in a user-ergonomic way in C. Regarding obviousness, I would add UB here, so Zig for example would beat it. C is not any closer t…
C not having fancy built-in structures means programmers are more careful about choosing simple ones, which dramatically cuts down the amount of completely pointless generated code. -O3 can optimize registers and maybe memory reads/writes, but it can't remove reallocation from each call to a vector push, remove a reference count from a whole object type, or do pretty much anything with any moderately complex heap data structure. Sure, that comes at the cost of more advanced things being horrible to write, but it's a trade-off.
And I'll just disagree that UB must be unobvious. To me, it's one of the most useful optimization tools. You can check for it with sanitizers, and explicitly invoke it to convey information about hidden behavior to a compiler. It's not magic.
C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.
C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.
On my last workplace we argued if we dared to use stdint.h, since it was so new and fancy. I was a proponent, but there is something calm over discussing whether to use 23 year old additions or not.