If you had 'random crashes', you probably weren't that good with C++ ...
None of your examples are a fault of the language - it is a fault of developer not doing necessary safety checks.
Buffer overflows, now, those are a special pain in C and C++. In many applications you don't need to work with arrays directly, though; and when you do need to do a lot of stuff with arrays, you probably also need it to run fast.
Not so sure about that. Here's a mistake: have a floating point variable somewhere and then don't initialize it. On it's first use, multiply it by 0.0. What do you think the chances are the result is 0.0? Hint: nan * 0.0 == nan, and there are many nan representations out there, so it solely depends on what pattern the memory location for that variable is initialized with. So unless your compiler created a bunch of code to initialize the memory for you, which it does not always do, I'd consider that pretty random.
No.
Should the developers of C++ take responsibility? Or just the consumers of the language? Why is one different from the other?
This entire argument that the users of C++ are at fault for everything is absurd. Users suffer for it, and no one truly takes responsibility.
If you forgot to initialise the variable before using it - it's your problem, not the problem of the language. This is a feature of C++, not a bug. It is well documented, it is expected, and it is there for a good reason. And if you are running into this issue all the time, perhaps C++ is not for you.
I don't see how, at all, and you haven't addressed how this somehow makes the C++ developer different from an engineer.
I think your analogy is absolutely imprecise.
And the people on the bridge aren't going to care.
> If you forgot to initialise the variable before using it - it's your problem, not the problem of the language.
Wrong! It's very clearly not the developer's problem, because they don't take responsibility. It's the end user's problem, because they're the ones who get hacked.
> It is well documented, it is expected
Oh, please. As if any C++ developer can spot every instance of UB.
> it is there for a good reason
Is it? This is an unfounded statement. Is there ever a good reason to read from an uninitialized variable? It's UB, so it seems like the language is telling you explicitly that it is not a good idea. But the language gives you not way of formally verifying that you don't.
> And if you are running into this issue all the time, perhaps C++ is not for you.
Alternatively, perhaps C++ is not for any human, as it's clearly far too complicated to reason about.
^ Well, replace "negligent" with "makes a mistake", and I've taken responsibility plenty of times. Situations happen. You do your best to mitigate mistakes in code within the constraints of your situation, but you don't always catch everything. Corner cases arise that you did not foresee, etc.
I have missed things that have caused user data corruption (or a similar problem) before, and when it was discovered I apologized to the user(s), fixed the problem and moved on. It's an imperfect world and I'm not omniscient. Yeah plenty of developers would just patch it, move on and not tell anyone, but there are a lot of us who care about the people we write code for and do the right thing.
My own skills dont necessarily matter. If you're working on a project with 100 devs, it only took one bad piece of code (or a bad library) to bring the whole thing down - which is a main downside to the language.
The only major additional problem C and C++ bring to the table is that some bugs manifest as subtle memory corruption, so the cause of the crash isn't immediately obvious.