Writing c++ that works correctly is not easy, and most people are not very interested in making sure the behaviour of the code is correct. There's a lot of c++ written by people under time and budget pressures that make it very difficult to take safety and correctness seriously. Naturally, this means that there's a lot of production software with serious bugs in it.
Nevertheless, this software is used by many people. It's surprising to me how error-tolerant people can be of software. Yossi Kreinin has written that "things want to work, not punish errors." He offers a couple of explanations for why things often work out despite being produced under conditions that are far from ideal. I understand him to be giving a few different reasons for this, so I'd like to see which of these could apply to c++ code.
First, "a solution wants you to find it." Each piece of the solution points you towards the next piece that fits with it. Even if your solution is not quite right, you might be able to get to a working solution by just modifying your broken solution a bit. This seems pretty language-agnostic and applicable for c++. For example, once you've written a component that solves part of a problem, the API of that component dictates how you use it. There's also a wonderful essay by Richard P. Gabriel about how things participate in their own design.
Next, Kreinin says that people are particularly tolerant a solution's flaws when the solution is giving them a lot of value, meaning that "reality punishes bad management the least in the most impactful cases." I've certainly seen this when watching people interact with buggy software. As an addendum to this, many people are mandated to use particular software by their workplaces and other institutions that they must interact with, meaning they have no choice but to accept broken software.
Finally, he notes that "risk-taking is actually rewarding as long as the downside doesn't materialize." When writing c++, it's very easy to write bugs that will only affect a small fraction of users, or are only relevant when deliberately exploited. If I'm not going out of my way to look for these sorts of issues when writing c++, then chances are high that they exist, but I've saved the effort of looking for them. Of course, the design of c++ makes it very easy to write software with these sorts of bugs.
It's sad to think about how many people must be harmed by broken software. We shouldn't take it for granted that software works correctly just because it's widely used. While I expect that organisations could improve the quality of their c++ software significantly if they chose to focus on it, that seems unlikely to happen, which is why I think it's better to write software using tools that prevent these sorts of bugs in the first place.