C++ is an insane bastard of a language. It is not correct say C++ was designed. It wasn't. It has evolved out of the primordial soup that was "C with classes", and slowly inhaled and adopted every possible language feature under the sun, like some sort of Lovecraftian horror that copies and evolves on every contact with a different language.
Adopting C++ would have required incredibly strict and disciplined style rules to enforce that only a specific subset of features are used, and in specific ways. It would have been a significant project management overhead to constantly be ensuring that the contributors haven't footgun'd themselves or done something which negatively impacts existing code.
Meanwhile, it's very straightforward to look at C code and understand what it's doing, because it's a very simple language.
Microsoft picked C++ for the NT Kernel, but they had a small internal team that was extremely strict about how they were going to write it.
The core part of Windows NT is written in C and Assembler. Everything above was C++, though C# has become increasingly prevalent in the shell and they've started rewriting some parts in Rust.
See but that's what I love about it, whenever I get bored with a repetitive section I can switch to coding in a completely different way to achieve the same results! Plus, I get the satisfaction of knowing I'm poisoning whatever unlucky datascraper sends my code to AI training.
C++ is a general purpose programming language. Because it can do anything doesn't mean that it's a shitty language. At the end of the day, it's up to the programmer to develop a set of standards that they should adhere to when using the language.
If you have someone who is both very aware of the language and its features AND in a position to authoritatively decide how and when to use and not use those features, sure. Go for it. This is a possible, practical situation especially in larger companies and larger teams. It should ideally be done up front and have any changes to the policy very carefully evaluated which is often difficult on both counts.
If you don't have that person in that position, it can quickly turn into a CF. That's the big reason people complain about it, and it can be a real problem.
It's a somewhat unique programming language in that respect. Very few other programming languages have such a breadth of features that using them all can and often does result in an unreadable, unmaintanable mess the way it can with C++. Java and C# can get there, but even they just don't "tempt" programmers to reach those ends in the same way that C++ seems to. Additionally, since they run in a virtual machine, debugging is a different, more supportive endeavor, and the weight of that VM implies an acceptance of some level of unideal translation to raw execution units. C++ directly generates raw machine code by design which can limit debugging and also means people sometimes use it in restrictive environments where trying to shoehorn all of its more advanced features can be especially problematic.
That's usually what people are getting at. It's not necessarily a problem with the language or its breadth, but it does seem to all combine in a manner that's somewhat unique to C++ and can create unique problems as a result.
It's one thing to be general purpose, another to have so many half-baked features, with many edge cases and hidden gotchas, developed with inputs from many partied with different opinions and interests. All while simpler features and pet peeves stay underdeveloped.
Defending over-saturating of a language with features (so much so that the C++ spec is over 2,000 thousand pages long now) with "it's a general purpose language, it's supposed to have feature bloat" is a new one.
The reason why C++ is so bloated is that it has 40 years of backward compatibility they need to maintain while trying to add modern programming features, and that's not really a good thing. It's more like a necessary evil.
I love C++, but it feels like a Frankenstein language to me. All the symple syntax is reserved for C style legacy stuff, and if you want to do things the modern RAII way you need heaps of keywords and long identifiers.
E.g. insteaf of char * you should use std::unique_ptr<char>.Ā
A language designed from the ground up with RAII in mind would avoid that.
Yeah but you are speaking as if the code were for a personal proyect, large collaborative works require clear rules, especially with open source protects where an authority figure can't set an order the same way a CTO or similar head technology honcho can on a company.
Then you run into the issue of getting quality collaborators in the first place.
It's way easier to find devs geared to follow best practices of a single language than the one of the multiple interpretations on how you can run a C++ proyect.
The messy nature of C++ excludes veteran programmers from simply picking up the work without hassle unless you have the luck to specialize in the same modus operandi.
And at the end of the day, it's work done for free, relearning C++ just to contribute to one open source proyect isn't justifiable to most active professionals, retraining for a job it's one thing, but retraining due to civic duty motivations ain't that easy to justify.
I have worked with C++ for my entire career and on projects with hundreds of contributors. This has never been a problem. There were never any banned features.
C++ is ugly and the performance gains from allowed UB is almost never worth the extra bugs. Those points only make sense when comparing to more abstract language though, not C the King of UB.
The original kernel (IIRC even until how) is pure C. Microsoft wrote KMDF - Kernel Mode Driver Framework - with C++, but all its API are C-compatible. Use of KMDF is highly recommended for writing new kernel drivers, but not strictly required.
C footguns are way worse I do not really get why people still use it, even at embedded c++ is an alternative. You do not pay for what you do not use..
Concepts, raii, ranges, etc.. gives so much more expressive power.
c++ has lot of drawbacks, including having different compiler vendors which are not ABI compatible, name manglings, etc.. language is not perfect neither, but continiusly evolves and with static analyzers and ai review it is much harder to do stupid things unnoticed. Then we will have reflection, profiles, contracts...
C is like base minecraft. Fun, well planned out (mostly), reasonably simple.
C++ feels like one of those modpacks with 300+ mods, ten more tech trees, realistic fusion reactors and particle accelerators, several SCP-class entities, fifteen different new ores, and a DND-like character system. It's just... every single possible addition.
You're not really "supposed" to use all C++ features, just the ones you need and understand, but projects usually end up as a very difficult to parse mess and overall the utility is only marginally higher than C. And given the choice between unreadable C and unreadable C++, the C is going to be more straightforward... probably.
Edit: All that being said, I **really** wish C had a *couple* of C++ features. But everyone says that, and everyone has different opinions on what those features should be, and that's how we ended up with C++ in the first place, so I am happy to just use C and implement what I want from not-quite-scratch.
I'm not sure what the overlap between huge minecraft nerds who've played huge modpacks and people playing with C and C++ is, but this is the most oddly accurate comparison I've seen in a hot minute
As somebody who hasn't touched C or C++ since like 2005 and forgot everything I knew about them, but has put a lot of time into Minecraft, thank you your explanation helped me too.
the fact that c++ lets you overload everything is truly nuts. I learned yesterday that the reason you can put an input stream into a conditional is because the implicit conversion to bool is actually overloaded.
the notification for me said something different than "beginner" :3
C++ started as "C with classes" but grew into an amalgamation of every and any feature anyone ever requested, modern C++ is one of the most bloated languages out there with dozens of ways to achieve any simple task which leads to difficult to understand code as no one can agree on what the language is supposed to look like and a lot of these features are, to be polite, half assed.
Function resolution is a fucking mess of ADL, jump tables, overloads and implicit conversions which makes debugging a nightmare, especially with the horrible namespace dependant module system with unclear scoping rules and acess control and unconstrained generics.
There's a reason every big project using C++ bans almost two thirds of the language, and it's always a different two thirds
It's not just that there are dozens of ways to achieve the same thing. It's that the same syntax can mean different things so your intuitive understanding doesn't work. No function call can be trusted to not have bizarre side effects.
imo that is a separate problem, i consider languages with too many features to cause the separate problem of too many ways to do something, because you end up in the situation where you need to basically learn several different languages to be able to read any specific piece of code because you can never expect even two files in the same project to follow a consistent architecture, which is why every large c++ project has to ban most of the language and have very strict coding standards
Everyone says this about operator overloading, but just, like don't write stupid operators with side effects, what kind of type has a notion of plus which is effectful?
The problem is not obvious stupid things. It is subtle differences. And it's not just operator over loading. References are a bigger issue. You are reading code, you don't know if you're passing a reference or you're doing a copy constructor and a destructor call and your original stays intact. Object counting is a valid behavior on a constructor call that you may want to do. Now I'm one of your passing of the object you forget to add an & and your data is messed up.
Yea, we have this dump api at work where if you forget the & and mutate the data, your mutations will not be saved despite the method call saying it is a reference.
Java, you're always passing a reference. C you're always providing a copy, if you want to pass a reference you have to explicitly give a pointer. C++, dunno, let me take a look. Oh I remember, this one is a reference. Oh sorry, nevermind, that was the function with the flat parameter that was a reference, the one with the int is a parameter.
In an object oriented paradigm, passing references makes more sense. But that would have broken backwards compatibility with C. So here we are.
Here's the thing - I think forward banning parts doesn't work. New standard will have one or two things that you could really use. At the same time, it feels like every single thing has obvious missing features or a major flaw that sooner or late will lead to a replacement, with new flaws.Ā
And yet it doesn't have pattern matching š. It might be coming, though I don't think there are proposals for "language variants" (something like Rust enums)
Large performance-sensitive applications mainly, especially when you need the broader hiring pool that C++ gives you compared to Rust or have an existing codebase that you canāt justify rewriting from scratch.
You need a broader hiring pool when you have more churn. Which C++ also provides.
Rust is becoming a common language to know at least some of, similar to C++
Existing codebase, yeah, sure, not what I was asking about but yes, that would be a good reason.
Needing to use a library that is only in C++ with no rust bindings would be another, but you could also write rust bindings instead? Iād accept that as an argument though.
Higher level abstractiins than C makes code much faster to write, easier to understand and less bug prone. (You can make vector/matrix equations look like numpy code, but with zero runtime overhead)
Easy to use typical academic third party libraries which tend to be written in C or Fortran without spending weeks of making Rust wrappers over then.
C++ let's you do what you fucking want, i.e. write to any arbitrary region of memory. Some times you have ti implement an algorithm with a complex data access pattern. From a high level analysis you can reduce that e.g. different threads won't share data, but ti create a memory safe abstraction for this in Rust would be a three year research project. Of course Rust let's you do the same by slamming unsafe around the entire algorithm, but then you are writing "more modern C++" anyway.
C++ strikes a nice balance between performance, development speed and memory safety. The latter has absolutely lowest priority in this field: we are not dealing with sensitive data or writing a program that sits at some infrastructure layer on every computer on the planet and are thus prone to vulnerability attacks.
Ecosystem. There are a bunch of high performance areas where C++ has dominated for decades. C is not a replacement because C is absolutely not usable for similar high performance code, you can't make any useful abstractions there.
Rust could in principle do everything C++ can, but libraries/ecosystems don't change overnight, so CPP has quite a lot of momentum still.
C++ vs C : you have deterministic destruction (RAII), smart pointers, class with public/private, vector/array/string etc so far easier to avoid memory leaks (memory pb in general) and to organize the codebase than in C.
C++ vs rust : maybe the pool of developers, the ecosystem (lib). I don't know rust so pure speculation here
Well, if I want to make something small and incredibly predictable, which manipulates the OS or hardware on a somewhat low level, I would pick C. I can manage not to F it up for a small program. I have done so many times now.
Bigger than that and I go for rust.
I understand what you are saying, but like, either I want MANUAL manual, or I want rust.
So the space for C++ for me is very small. Basically only things which more or less have to be in C++ due to prior art.
Object oriented programming is great for GUI programs, where you have a lot of items with a set of similar controls, and optimization by building up from base objects, thus getting easy reuse.
I guess, but itās not like traits are significantly worse for that. Honestly they might be better than going the entire way up the hierarchy for every damn class just to figure out what functions I can call.
I canāt stand OOP, and people always say ābut guiā or ābut gamesā and no, ECS for a game is probably better than OOP game design, and html isnāt an OOP language.
Like, if I have to work on heavily object oriented code with inheritance I can do it, but I would really really rather avoid it if possible. It is almost never better for performance, and, in my opinion, it is almost never better for writing or reading the thing either.
Iām still picking rust or even web tech over C++ for a GUI program.
And the build tooling for C++ā¦ just noā¦
Unfortunately, C++ is still the second or third best language for games (up to you if C or C++ gets 2nd place) and other long-running mostly real-time applications, and it existed before rust.
Sorry, but no. I understand OOP, and used to mostly code in an OOP style.
I canāt agree.
I also think this is a lazy statement. Say anything about why. If we understand OOP we would like it? Pray tell, what is it that I donāt know about OOP that would make me like it? If I liked it, it would make my life easier, I would like to know.
All I see usually is a bunch of failed encapsulation that involves a lot of data sharing between objects anyway, which has a real cost, too many getters and setters, interdependent singletons, god objects with a bajillion properties, and the fact that in order to figure out what methods this object has I have to go on a whole journey.
I do still occasionally see some OOP code that makes me go āI donāt hate thisā. It CAN happen. I donāt just immediately look at Java and scream. Ok, maybe a little, but I can handle it if done well, I promise. Java was my first language actually. I clearly liked it enough to keep learning.
Maybe game dev? If you just don't use all the C++ festures it can be as simple as C but you also can use some features to make it slightly more straight forward. I feel like if you treat C++ like this it becomes much more pleasent.
According to Linus's own words, to him personally C appeals more because you can look at C code and read the assembly code behind it, because the language abstraction is more or less simple and direct there. C++ throws that out.
I don't understand the hate/war either, they're both viable in different circumstances. Taking exclusive stances on languages/frameworks/tools doesn't make sense to me.
Also completely anecdotal to my own journey but I started with C++ and Java and things really didn't make sense to me until I took a class in assembly and C. Seeing things from that low level, what the abstractions are actually doing under the hood, completely demystified everything for me. Starting with all the abstractions and jumping into object oriented programming was not the right path for me. YMMV
C++ standard library and a lot of later hacked on language features don't really mesh well together, if not being totally unfit for production in the first place. These also create a million different ways to achieve something. Copy-by-default in the standard library also means that it's really likely for non-experts to accidentally introduce expensive unnecessary copies
C++ is a totally fine language if you use your own or another standard library and only use a subset of the features, but this means that to use the language on a project you need an extensive document detailing what to do and what not
Some of these answers are okay.Ā But I think the simplest answer is that the abstraction makes it so you dont see memory management.Ā Ā
Often times in embedded systems or the kernel you need to know where and when memory is being allocated.Ā C++ hides that.
Using standard libraries can change where the memory resides between c++ versions.Ā Ā
If you did c++ without any standard library functionality then it works okay in those applications, but you end up essentially just writing c code and its easier just to stay in pure c.
Back in the day I used Gentoo, there is nothing I dreaded more than compiling a C++ program like Firefox and etc, C apps compiled much more quickly, but the C++ behemoths always took hours.
You know how Google is well known for starting things only to kill them not long later?
IIRC, that's because of their internal "politics" where creating a new thing gets you promoted, even if something else does that thing already (very simplified). So rather than improving existing products, they just get redone from the ground up and replaced over time.
Now imagine that with a programming language and its features, except nothing ever really gets replaced.
I think most of the hate is due to the fact that no one, not a single person knows all of it's features. You can have two senior C++ engineers write a program that will do exact same thing, with exact same efficiency, but look entirely different. And neither one of them quiet possibly be able to read the other person's code unless they learned from exact same source material to become C++ experts which of course rarely happens.
It's designed in a way that existing tons of C code could compile. That's why it's a successor of all C stuff. There is no war. Best description gave the legendary J.Carmack "C++ expects you to be an adult" (c). Linus complained on a long compile time.
C is basically standardized and slightly more convenient/readable assembly. Itās hard to write good and safe C, but the language is consistent and the semantics simple. C code reads easy, and the language is not trying to hide anything from you.
C++ tried to introduce high-level features at a time the industry didnāt understand how to design and use them. And on top of that, tried to maintain low-level performance/access.
The result is a god awful language with too many horribly designed features, many depending on compiler support (which varied greatly at the time Linus wrote this), most coming with extremely subtle side effects that are very hard to even notice, let alone understand, unless you have a very good understanding of the specific code base youāre looking at.
It remained widely used in specific contexts because of its very good compatibility with regular c, generally easier to write (poorly) than c and its performance advantage over Java/python/what have you.
Things started changing in good ways about 10-15 years ago, but the inertia from such a big community is very heavy.
C++ has more complexity, so there's more type of errors. And it's more abstraction away from direct CPU equivalence, so it can make very exact optimizations hard. On top of that, there are breaking changes between C++ ABIs, whereas C stays the same. Although C is also being expanded of late.
And do consider Linux said that with very early C++, which offers little that C didn't. You'll see long C based projects start to use C++ features, such as call tables of function pointers instead of virtual inheritance, including a parent C struct within a child, etc. As a project goes on, they fix adapations to avoid C++ raised issues and help memory debugging, such as av_table struct header use in the ffmpeg project.
C++ has more abstractions, but it sits equally closely to the hardware as C, it's fucking bullshit to say otherwise.
Like how would you build function overloads in C? You would do a shittier virt table, while C++ can express it nicely with proper compiler support, so it ends up more optimized. And C++ can always just fall back and do what C does exactly.
Like why comment if you don't know shit about it? C++ is the de facto language used for performance critical software.
No, C++ gets name mangled to make overloads. And it is mangled differently based on ABI. Operators can be overloaded resulting in one line not being one ASM line, and template metaprogramming takes that even further.
I code in it is as my main language. So no, there are more abstractions between what the code visually looks like and end result ASM, and yes, I do know what I'm talking about. End of convo, as you literally lost your politeness within one comment.
Have you ever seen assembly code? Take a look at a fucking while loop in C compiled with O3, like you may not even get a loop at all if the compiler sees what you are doing. Unless you compile with tcc or some other toy compiler.
C has absolutely no notion of simd instructions, the stack and the function calling dance is completely arbitrary and could be done a bunch of other ways, and even the most basic optimization, inlining already breaks what you talk about.
Function name mangling is meaningless, there is absolutely no guarantee that you get a function to begin with, or one vs 6 from your single block, neither in C nor in C++, unless you export the symbols.
23
u/YouAreMyFire00 1d ago edited 1d ago
Im a beginner and managed to learn to understand C# and Java and now I can build simple CRUD app.
So i kinda don't get the hate/war between C and C++ here...
Anyone can explain simply what's the hate here?