|
|
|
|
|
|
by jenadine
1046 days ago
|
|
|
No, C is not better. C is much worse. C lacks basic primitives that allow programmers to do useful abstractions and let them concentrate on the business logic rather than on the low level details of every functions. You maybe can write small program easier on C as long as you can fit everything in someone's head. And that's why all complex low level programs are written in C++ and not C. (With the Linux Kernel being an exception, because of its stupborn maintainer) And what about the drawbacks mentioned on the article? 99% of programmers don't need to care about them. The reasons such article exists is precisely because some people love C++ and like to play with their language. --- > If C++ is so good why does it need to be constantly updated and extended? Uh? To adapt and evolve to a changing environment. Instead of stagnating and becoming irrelevant.
If it is so great, why is the iPhone constantly release new models? Why do every maintained software release new versions?
And that's why you should use C++ instead of C. |
|
|
I explained why it doesn't matter that "C lacks basic primitives...". C has the basic primitives. It lacks generalist containers, for example. But most of those 'generalist containers' are, as I already explained, just not very good. For example, take this post:
https://zeux.io/2023/06/30/efficient-jagged-arrays/
What do we see here? The guy starts off with basically 'normal C++' and what he has at the end if essentially something you could write in C. When you optimise C++, you end up getting C. He has two std::vectors, but they're pre-sized so they're essentially the same as writing 'unsigned offsets = calloc(vertex_count + 1, sizeof offsets);'. This is not any kind of significant boilerplate.
The low-level details are something you NEED to concentrate on. If you don't care about the low-level details, then you shouldn't use C or C++. That's the point of low-level languages: control over low-level details.
All complex low-level programs are written in C. C is used in every production operating system kernel. C is the language in which systemd is written. It's the language in which pretty much every production web server or network server is written in. It's the language used by pretty much everyone interfacing with hardware.
The Linux kernel isn't an exception. It is the typical case.
>And what about the drawbacks mentioned on the article? 99% of programmers don't need to care about them.
The drawbacks mentioned in the article are major issues. They regularly bite C++ programmers, and are always lurking. You can't just say '99% of programmers don't need to care about them'. The whole point of namespaces in C++ was that you didn't need to care about name clashes. The result of argument-dependent lookup is that instead of getting a linker error on a name clash, like you do in a sane language, you instead can get random weird functions being called, silently.
>Uh? To adapt and evolve to a changing environment. Instead of stagnating and becoming irrelevant.
You've missed the point. You say C++ is so wonderful, but it's one of the languages that today is changing the most in idiom and specification. Since C++11, we're constantly being told about the new 'proper' way of doing things in C++. They're adding new features then going 'oh actually that was a bad idea' in every new revision. If it were so great, why would it be changing so much?
None of its changes are to 'evolve to a changing environment'. In C++11? Sure, they added threads, they added atomics. Pretty hard to argue that it wasn't an evolution to adapt to the new multithreading world. But today C++ still doesn't even have a networking API standardised. It still doesn't have a decent filesystem API. It can't even adapt to the world that existed when it was FIRST standardised, back in 1996. How is anything they're doing adapting to the world of today?
---
Really none of what you said addressed anything I actually said.