Is there a reason to use C++ any more? Has anyone gone back and had good experience? I'd kinda like to but am wary of the old problems. (The other problem is that most interesting business logic is no longer in C++.)
Its a whole new language and much more stable when you just use smart pointers, take care of ownership and know how to use the right reference types.
If you were referring to Java/dotnet/python, well yeah. (I'm honestly curious to know what you meant).
Compared to PHP, Python, Ruby, C#, Java, JavaScript: true with some pedantic exceptions.
Compared to Haskell, oCaml: Usually true, unless facing both well-suited and well-tuned code.
Compared to small volumes of carefully crafted and profiled Fortran, C or Assembly: usually not true.
Compared to CUDA: Not true for applications well suited to GPUs. Still true for situations that map poorly to GPUs. Except CUDA is almost entirely C++! Recent CUDA compilers on recent GPUs handle C++ code directly very well. Nearly everything but exceptions and thread local storage is supported.
"C++ can produce very fast and memory efficient programs." would have been fine -- or some variant that compared it to specific languages, such as you do above.
I don't think it's being pedantic at all to ask what the OP meant. It was a vague statement that (depending on what they meant) is either true or false.
Remember that the original question was: ...moved to Java/dotnet/python platforms...Is there a reason to use C++ any more?
^ Yeah, and I specifically addressed that possibility in my original response to you.
I was just trying to clarify whether you were referring to that comparison, or a comparison of C++ vs all other languages. It was not clear to me which you meant. Perhaps it was just the way I read it at the time.
It was not clear to me whether gcp's statement was supposed to be limited to a comparison between C++ and Java/dotnet/python (and I addressed that in the post that you responded to). I felt it was worth the qualification for the sake of discussion, and I still don't think it was being pedantic to ask (especially since I addressed the possibility of it being the above comparison). I wasn't just nitpicking for the sake of nitpicking. And my question was a far cry from asking him to "defend a mathematical thesis", IMHO.
Now if the metric is startup time, that's a different story. (Though I believe there's been a lot of work on hybrid AOT/JIT since I left the world of managed languages, so maybe things are better now.)
Which is the #1 requirement for a bunch of applications. I can feel I want to go back...
Which means whoever wrote the code was doing it wrong. Which is not that strange given C++ really did (and still sort of does) make it easy to make certain mistakes. But which could be countered by a better understanding and learning of the pitfalls.
Good news is: all of that got in my opinion better since C++11 and beyond. Lots of cruft still there of course, but most of the time you don't need to touch it. And if you do have to, you're ither doing it wrong, or there's a really good reason for it. Should you start from scratch, using a proper book or tutorial, you shouldn't have too much problems. If you don't start from scratch, you're going to have to spend extra time in forgetting a bunch of things you learned about C++. I've seen more than a couple of programmers really struggling going from C to C++03 (and as a result writing C with a class here and there and, god forbid, even using a vector or string or algorithm), and from C++03 to C++17 is not that different.
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.
None of your examples are a fault of the language - it is a fault of developer not doing necessary safety checks.
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.