One of the biggest misconceptions in programming is that coding in C++ is nightmarishly hard. I’ve been working in C++ professionally for close to 15 years (though my current role is Python). I’ve done graphics, UI, backend systems, low level bits and bytes concurrency laden code, you name it, and I can attest to it not being so bad. In many ways, it can even be easier than Python when working with more complex and nested codebase because it’s so flexible yet so expressive.
C++ is a big, complex language and learning all of its intricacies like many C++ classes nowadays teach is daunting. And that’s where I believe the problems lie. You don’t need to know everything about C++ to start working with it day to day, just the fundamentals. Remember, it was the first language taught to older millennials for a reason.
> Remember, it was the first language taught to older millennials for a reason.
For the reason that it was the only reasonably available language for a while, I'm afraid. I too have written enough C++ in my professional works; nowadays I work with Rust and Python though, my last professional C++ was C++14. And C++ only kinda works when someone with enough mistakes and thus enough knowledges organize the code base in the way that others won't easily make such mistakes. The language doesn't really help you---which is often a pro, but much more frequently a con. That's not a good place for beginners to start at the very least.
> For the reason that it was the only reasonably available language for a while
Weren't there other popular, cross-platform programming languages in the 1990s and late 1980s? Like Pascal, and Basic? Those both seem like simpler languages, and easier to teach as first programming languages than C++.
Yeah, I was missing a word there but I couldn't think of the exact word. I believe Pascal and Basic were usually regarded as teaching languages as opposed to practical languages, so (while I'm against such line of thoughts) many colleges and universities decided to go straight into production languages because they will need them after graduation anyway. Later Java and Python were used as that kind of "practical first languages".
That makes sense. I've heard that sentiment about "teaching languages".
I wonder how Pascal ever became so popular given that it was regarded as a teaching language. It was clearly a contender in industry for a while; for example, Apple originally used Pascal for the Macintosh, and Turbo Pascal was extremely popular.
Nowadays, we don't even have "teaching languages". Students are taught something like Python, JavaScript, or Java.
It isn’t as hard as people make out but it also isn’t easy. The saving grace is that the language, particularly in its modern form, is highly amenable to an experienced user designing their own libraries that make the language much nicer to use. You can replace most of the dubious parts. Nonetheless, C++ is unreasonably large.
The main advantage of something like C++20 is that for some types of software there is no other language that comes close in both performance and economy. The alternatives either require much more code or giving up a lot of performance, neither of which is particularly palatable for many use cases. I am always keeping an eye out for smaller languages with similar economy and performance.
> The main advantage of something like C++20 is that for some types of software there is no other language that comes close in both performance and economy.
Um, there are plenty of Crab People[0] around here who would quibble with that statement.
I used to love C++, template wrangling :-P aah, but pretty much gave up after C++11. Right about the time when Scott Meyers also said: "enough" (paraphrasing).
My biggest issue for giving up was the ever growing list of "don't"-s, its not fun to write in language where the design is so "loose" that to get reasonably correct/predictable code you always have to reference the list of "don't"-s.
And then having been a build maintainer on various projects the build and package management was a nightmare. Still vividly remember the first time I looked at Rust's cargo - mind blown :-)
IMHO C++11 changes (and many of the later ones too) make the language substantially better than it was prior.
I do personally hate the package management story which is why I try to only use single header libraries (I only use C++ for personal projects so I have control over what I use). I absolutely despise cmake, but Rust’s cargo is fantastic.
To add to this, you can easily learn to use the newest features. I cringe every time I read or hear "C++ has become so huge and complicated". It only takes 20 minutes to get proficient in the newest features such as modules and concepts. People hear "polymorphic lambdas" and imagine something so complicated, it came out of the Necronomicon. No, you simply replace your lambda parameters with auto and the compiler takes care of the types and that's it. And variadic templates aren't going to eat your soul if you can read code that has recursion.
IMO C/C++ are great languages if you learn how memory and pointers etc. work. The tooling on the other hand is horrendous when you compare it to other languages like Rust.
You don't really need to do much explicit memory handling in modern C++ - smart pointers feel similar to garbage collected languages like Java or Go, with the occasional extra '*' I guess.
Comparing language tooling to Rust is surely controversial when compiles in Rust take an order of magnitude longer than any other language. Sure, Rust's tooling has some nice features but let's not ignore this very important elephant in the room.
Cargo is i) not a compiler, and ii) moving to the sparse index protocol [1] that do not fetch the whole index anyway. And even the older git protocol won't fetch the same data twice.
As a fairly avid Rust user I can say I'm excited to hear that! Just playing a little devil's advocate for fun.
That said I was moderately upset by this Friday after carefully assembling a development container for a project at work. Guess I'll have to make something persistent somewhere if I don't want to twiddle my thumbs before each build.
I'd say a lot of this is a form of survivorship bias. I've programmed in C++ since the mid 90s so I am used to a lot of C++'s issues, but I also run a company and have to train new engineers and I see first hand the absolute nightmare that a lot of people encounter learning this language and it's demoralizing. While to me a lot of this is stuff I managed to figure out, I also understand that for many new developers this is just crap that no one should have to deal with in 2023.
Lack of a good way to build third party libraries, build times that are astronomical and a true productivity killer, error messages that are entirely unhelpful and can produce giant walls of text for the most trivial of reasons, rampant undefined behavior that is incredibly hard to identify.
Several things changed my view on C++ and now I see it mostly as a sort of zombie language.
1. As I mentioned once I started my own business and needed to train new engineers on how to use C++, I started to look at the language from a fresh point of view and realized it really is a complex mess just to get basic things working.
2. Scott Meyers "retiring" from C++, and in particular this video:
3. I attended an ISO C++ meeting in Toronto and while I absolutely found that the people were very intelligent and knowledgeable, as well as well intentioned, I realized just how political C++ is and that much of its development and complexity is not due to technical constraints or driven based on what is in the best interest of the C++ community or research, but really based on name recognition and a lot of politics.
Unfortunately Bjarne himself has been responsible for a lot of political issues with C++ that could have easily been avoided such as the obvious warts with brace initialization and the paper he wrote that basically pushed out two of the most prominent members of the C++ community, Walter Bright and Andrei Alexandrescu over what seems like a bitter pissing contest he had with them:
C++ has had some improvements in the past decade for sure, but its future doesn't look too bright at this point. Features like modules are a convoluted mess that still don't work even 4 years after standardization. Coroutines are a lifetime and performance nightmare that was originally designed in particular to accommodate embedded platforms with no runtime, but are all but useless for that use case due to how they allocate memory, and concepts are really just a substitution of one hacky way of doing overload resolution with another hacky way of doing it.
> Coroutines are a lifetime and performance nightmare that was originally designed in particular to accommodate embedded platforms with no runtime, but are all but useless for that use case due to how they allocate memory, and concepts are really just a substitution of one hacky way of doing overload resolution with another hacky way of doing it.
Coroutines were originally pushed by Microsoft, based on .NET's async/await model, and C++/CX concurrency on WinRT (COM evolution) runtime.
Hence why you will find several talks and papers from Gor Nishanov, during C++'s coroutines early days, or that .NET has a similar way of adding magic methods to a class to transform it into a coroutine aware type.
The toolchain is completely unhelpful though. I can't make sense of half the compiler diagnostics that get spewed on my screen. If it wasn't for ChatGPT being able to reason about the compiler diagnostics, I'd be screwed.
I guess I'm lucky I've only been doing a spate of C++ for about 18 months. In the early stages before ChatGPT it was a bit tough but I was also working with admittedly simpler code (less templated code). I have a decent grasp of C including virtually every compiler/linker error that a C compiler would spit out, so I could manage a lot of the superset style errors, but as more C++ work came in, the more inscrutable the diagnostics.
I really enjoy programming in C++, but agree on knot being able to know all of it. It’s just not necessary to know it all. I think this comes with programmer experience too, learning to learn what one needs to know right now along with some very high level of whats available goes a long way. Then when one needs to reach elsewhere, they have an idea of where to go, but none of the details yet. But knowing how to program also means that a large chunk of the problem of using the best language for the job is easier. Doing it idiomatically though, that takes work, but at least knowing the questions is a big start.
My experience of the language has been similar, including the bit about it no longer being part of my life.
For a long time, the complaint was that it was being used as nothing more than a "better C", though in my experience, the worst abuses came from among those who were determined to use every feature.
In the beginning, the fact that early C++ was a superset of C is probably what led to its widespread adoption, but the legacy of that decision, particularly with regard to pointers and pointer arithmetic, has been a multiplier of complexity.
The D language dynamic array, which is a pointer+length pair, has (over time) nearly completely supplanted pointer arithmetic. The pair prevents buffer overflows and underflows.
Raw pointer arithmetic is not allowed in code marked @safe.
I very rarely find a use for pointers anymore. Often a whole program has none at all, not even unique_ptr<>. When I do use them, they are front-and-center enough to make mistakes unlikely.
I also rarely use them, but sometimes pointers (via virtual methods and factories) can reduce compile times a lot for components with a stable API but high complexity and churn of the internals. Do you have another way to handle that?
I tend to rely on member unique_ptr for such concerns. At top level, you still don't see any pointers. Of course at machine level the code is absolutely lousy with pointers, likewise at the next level up, but the pointers you can't see because they are buried in libraries cannot generate bugs.
And therein lies the actual problem. C++ killed the one saving grace of C, it's relative simplicity, and created a language that is a dumping ground of ideas.
The notion that you just "learn what you need" is an anathema. Not knowing a language, and all it's subtleties, is just a form of hacking. You end up encountering things which you don't understand and have to hope you don't cause unknown problems and muddle through.
That C++ is widely used by professionals who don't understand their tools is just another reason why software is so crappy these days.
> C++ killed the one saving grace of C, it's relative simplicity, and created a language that is a dumping ground of ideas.
I think the average C++ programmer is pretty aware of the language's downsides. It's still a language with important practical upsides though: there are plenty of C++ programmers out there for hire, there are many existing C++ projects that need to be worked on, and it has a strong ecosystem of compilers and libraries.
There seems to be little prospect of C++ losing its near-monopoly in core game-engine code, for instance.
(I say all this as someone who usually gives C++ a hard time for its poor safety, and associated security issues.)
> That C++ is widely used by professionals who don't understand their tools is just another reason why software is so crappy these days.
No doubt there are many security issues with those roots, and many instances of code that's needlessly non-portable. Those are due to specific issues with C++ though, not its general complexity.
I imagine the practical consequence of the language's complexity is to drag out development times, rather than to undermine software quality. I haven't given this too much thought though, and this is essentially a guess.
> The notion that you just "learn what you need" is an anathema.
I agree this idea makes little sense. If you work in a team, you may be asked to debug someone else's code. If you're going to work with C++, there's no denying the value in having a deep knowledge of the language.
Right... doing that specialized subset of a language that makes sense for you might not make sense for your team, might not make sense for your next team, and so on.
Plus, every library is using a different subset, so it’s not as if you can stay within your preferred subset either.
I worked in a project that had 6 different string classes: std::string, opencv, vtk, qt … plus a wrapper around all of the above that converted this mess to a plain C string so you could actually use it. A real nightmare, with no good way out.
I’m sure some C++ person will say “it’s not the fault of the language, it’s simply that those libraries are not proper C++23”, missing the fact that those are some of the most prolific, well-maintained and widely used projects in the C++ world. If even those can’t get it right, then the problem must surely lie with the underlying language itself, and with the committee who is defining how it’s supposed to work.
Most likely they do get it right for their problem domain.
If the people who made opencv, vtk and qt had to make it in another language with the design constraints they had (which can sometimes be as simple as insisting on using CamelCase instead of snake_case for historical reasons) they would likely make their own string / array / matrix / ... type in that language too tailored to their exact problem domain.
Can you express value semantics in Python, or is everything still passed by mutable reference still and duck-typed at runtime? I’m being flip, and I like Python for some things, but for large robust performant software I find C++ way easier to work with as it works with me not against me to wrangle complexity.
I have been trying newer languages these two years(rust,zig,nim,golang,dart) and I'm more than ever firmly believe c and (modern) c++ are all I need to get job done, fast.
The ecosystem, the no-FFI-needed reuse of so many libraries, books and tutorials, are just too valuable, yes c/c++ are not perfect but I failed to find things better.
MISRA's new c++ and c books are great to help me to write safe code as well.
Satellites and rockets and not "running c++". They are running compiled machine code, that may have been written in any language.
For satellites and rockets in particular, similar to other embedded systems, most of them have the software written in C, which makes sense. C++ doesn't have much to do with it.
I’m a big believer in the right tool, for the right job.
I used C++ for many years, as a primary development language for MacOS apps (MPW and CodeWarrior -mostly CodeWarrior).
I happily switched to Cocoa and ObjC, and it’s been Swift, for many years.
But I also write GUI end-user interface apps.
At the company I worked for, we used C++ to write image processing pipeline engines, and would install the engine in apps for Windows and Mac, which were written in C# or ObjC (my company had not switched to Swift, by the time we left).
Our team consisted of a number of highly experienced (like 30 years of coding, experienced) engineers, and they did a great job with C++.
It can present difficult-to-fix bugs, but that’s because of the type of tool it is.
I think of C++ as an “engine” tool. It’s best used to create “faceless” libraries and SDKs (IMO). In that context, it basically has no peer.
What qualities should this comment have to vouch for? The art style of the linked video? The accuracy of its content? Should we ask OP if they vouch for the video that started this thread?
I learnt C++ in the 90s. I internalized the various gotchas and learned to use a relatively safe and expressive subset of the language. I'm still programming in C++ now and (I'm slightly ashamed to say) haven't bothered to keep up with all the new features. I keep meaning to make the time, but there is always higher priority stuff to do. I use foreach plus the occasional lambda and auto type. What have I been missing?
Many years ago (1990-2005), I remember using C++ and whenever there was an error in some piece of code that involved strings (what should be a basic, fundamental data type), the error message referred to some complicated template type like std::basic_string<blah blah> and the simplest error was a really long message. It seems that no attention was paid to usability.
For some unholy, around 2004, reason I wrote a template library that encoded all of the crystallographic groups as integer template arguments; I guess the idea was to allow automated mapping of any point in the unit cell to its canonical cell position. That'd let us compute crystallographic distances in something like O(log n) time, rather than O(n). (The usual way is to copy one of the points to every equivalent point in the unit cell, calculate every distance in all directions, and keep the minimum: 200+ distance calculations in the worst case; the copies were made via sequences of 4x4 matrix multiplies.)
Anyways, I deployed this software, and someone had a misstep, and the error message crashed the mainframe. I relayed this story to Bjarne around 2006, and he didn't find it funny — just frustrating.
It is not hugely different today when you have an error in a template. I had a one line error using a boost multi index container. It produced 1300 lines of errors. You do kind of get used to it.
C and C++ distinguish between the language and its implementations (compiler plus runtime). Producing good error messages is the compiler's job, not the language's.
Depending on how the language works and what it allows you to do, your compiler's error messages can only be so helpful, though. I mean, imagine replacing "C and C++" in your message with "Brainfuck". Error messages would be guaranteed to be very low-level, so won't help you solve the actual higher-level problems.
Yes, but in the cited example of basic_string, providing useful error messages isn’t actually that hard. It would be more interesting to hear an argument about what specific C++ features make providing useful error messages hard (if indeed they do) for which precise reasons, that would warrant the accusation that the language designers (rather than he compiler writers) didn’t pay attention to usability.
Clang would be my recommendation. Though once clang showed better error messages were possible g++ cleaned up and things a much better than 15 years ago.
The fact that this video has less than 1000 views is insane. Probably not likely to stay this way now it hit the front page. However the audio is quite poor.
C++ is a big, complex language and learning all of its intricacies like many C++ classes nowadays teach is daunting. And that’s where I believe the problems lie. You don’t need to know everything about C++ to start working with it day to day, just the fundamentals. Remember, it was the first language taught to older millennials for a reason.