5 ms·

So I used C++ a long time ago but moved to Java/dotnet/python platforms. I do miss some low level stuff but not random crashes. Is there a reason to use C++ an

by rb808 9y ago

So I used C++ a long time ago but moved to Java/dotnet/python platforms. I do miss some low level stuff but not random crashes. 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++.)

hellofunk 9y ago
C++11 changed the language significantly and for the better, and each subsequent version has taken it further in the right direction. You can now use C++ as a high-level tool without much or any concern for manual memory management, and can do a lot of functional-style programming very easily and nicely. C++17 in particular adds features that bring the syntax closer to modern high-level languages almost to the degree that it feels like a scripting language at times. Stuff like automatic destructuring, variable definitions scoped for all branches of conditionals, etc. It's really one of my favorite languages, though this year I'm not getting to use it as much.
futurix 9y ago
If you had 'random crashes', you probably weren't that good with C++ ...
- meschi 9y ago
  Yeah, blame the user for the effects of broken design.
  - zlynx 9y ago
    If you resurrect objects in the GC finalizer, you probably weren't that good with Java.
    - oconnor0 9y ago
      It's significantly easier to be "bad" with C++ than it is to be "bad" with Java.
  - futurix 9y ago
    It is not broken, it just assumes more responsibility than most developers are willing to accept.
    - staticassertion 9y ago
      Really? You accept responsibility? In what way has any developer ever accepted responsibility for bad code? When an engineer is negligent and a bridge collapses, they are responsible - there's a whole system of insurance around it. When a developer is negligent and user data is compromised, do they take responsibility? 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.
      - futurix 9y ago
        In your example, the cause of the collapse would be that developer drove a tank onto the bridge and didn't bother to check the weight limits beforehand. 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.
        staticassertion 9y ago
        > In your example, the cause of the collapse would be that developer drove a tank onto the bridge and didn't bother to check the weight limits beforehand. 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.
  - ksk 9y ago
    I think calling it broken design is quite unfair. I'd say to constructively criticize a programming language you'd have to bring much more to the table. You can point to specifics in the syntax, grammar, rules etc along with an argument as to why they are problems.
- rb808 9y ago
  > If you had 'random crashes', you probably weren't that good with C++ 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.
  - iainmerrick 9y ago
    Isn't that true in any language, though? 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.
- maccard 9y ago
  I take it you've never made a mistake programming before then? A relatively trivial example is passing by const reference [0] While it's fairly clear in this example that you're getting a reference to a local variable, it can easily slip through if you pass something through a level or two of a function. Note there's no compiler warning for this. It also (probably) won't show up until you actually try and use St.m_x at some point, which may be in a very different place to where it was initialised. In most cases, if it shows up in an optimised build, you'll get next to 0 useful information from a debugger/stack trace. [0] https://godbolt.org/g/XTh5Mv https://godbolt.org/g/XTh5Mv
  - futurix 9y ago
    My beef here is with the word 'random'. Mistakes don't make for random crashes - hard to trace perhaps, but not random.
    - stinos 9y ago
      > not random 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.
      - futurix 9y ago
        Well, yes, but it is randomness of a mistake - not randomness of the language. If you are going to shoot yourself in the foot, I guess the wound would be pretty randomly located - but that is not the fault of the gun manufacturer.
- andreasgonewild 9y ago
  It's definitely getting easier, but I still wouldn't even consider C++ without valgrind or similar watching over my back; and I've been writing C++ since 1995. Accessing a variant value as the wrong type, dereferencing empty smart pointers and accessing non-existing elements in collections and many many more cases will still segfault; and I don't expect that to change since it lacks that level of security by design. That being said, it's still the most pragmatic language around; the only language that allows me to choose my own level of crazy.
  - farunen 9y ago
    @andreasgonewild: "It's definitely getting easier, but I still wouldn't even consider C++ without valgrind or similar watching over my back" That we still need such tools to help the compiler in 2017 tells me that programming languages haven't advance much. (moderators: yes I know, downvote and disable the account, cause any kind of disagreement is considered a micro-macro-micro-aggression, not to mention any attempt at humor).
  - futurix 9y ago
    Exactly! C++ is a language where you are free to choose level of safety. None of your examples are a fault of the language - it is a fault of developer not doing necessary safety checks.
    - johannes1234321 9y ago
      The point is: some languages have capabilities to take some classes of errors out. A language with GC and heap-allocation only makes it hard to get access-after-free-style errors. Languages with bounds checks on all elements reliably crash (throw an exception) instead of showing "random" behaviour on bad reads. Of course all of that comes with a cost, but for many domains that works out ...
  - iainmerrick 9y ago
    I don't find null pointers any worse in C++ than in Java or C#. Seg fault or a NullPointerException that you can't do anything useful with, take your pick. 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.
stinos 9y ago
random crashes 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.
gcp 9y ago
C++ still produces the fastest and most memory efficient programs.
- rb808 9y ago
  > C++ still produces the fastest and most memory efficient programs. Which is the #1 requirement for a bunch of applications. I can feel I want to go back...
- nocman 9y ago
  Fastest compared to what? Everything? That is definitely not true. If you were referring to Java/dotnet/python, well yeah. (I'm honestly curious to know what you meant).
  - corysama 9y ago
    Definitely not formally, pedantically true. But, we aren't defending a mathematical thesis here. We're having a casual discussion. Still... let's see: Given a generic workload with equal effort put into optimizations... Should you expect C++ to be faster? 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.
    - nocman 9y ago
      My point was that the statement "C++ still produces the fastest and most memory efficient programs." is basically meaningless without any context. There are a fair number of situations where other languages can beat C++ in either or both of those metrics. "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.
ksk 9y ago
I don't quite see how the "random crashes" were not a programmer error, unless you were using a terribly unstable/buggy library. If you want performance (in the real world, utilizing code you have, libraries you purchased/wrote, etc) C++ is the way to go. Java/dotnet/python are not comparable or interchangeable with C++. And like any tool you have to work within its limitations.
- oscargrouch 9y ago
  If the parent used C++ in the old days, using the "Better C" paradigm im sure he will have bad memories being plaged by manual resource management. 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.

by rb808 9y ago

hellofunk 9y ago

C++11 changed the language significantly and for the better, and each subsequent version has taken it further in the right direction. You can now use C++ as a high-level tool without much or any concern for manual memory management, and can do a lot of functional-style programming very easily and nicely. C++17 in particular adds features that bring the syntax closer to modern high-level languages almost to the degree that it feels like a scripting language at times. Stuff like automatic destructuring, variable definitions scoped for all branches of conditionals, etc. It's really one of my favorite languages, though this year I'm not getting to use it as much.

futurix 9y ago

If you had 'random crashes', you probably weren't that good with C++ ...

meschi 9y ago
Yeah, blame the user for the effects of broken design.
- zlynx 9y ago
  If you resurrect objects in the GC finalizer, you probably weren't that good with Java.
  - oconnor0 9y ago
    It's significantly easier to be "bad" with C++ than it is to be "bad" with Java.
- futurix 9y ago
  It is not broken, it just assumes more responsibility than most developers are willing to accept.
  - staticassertion 9y ago
    Really? You accept responsibility? In what way has any developer ever accepted responsibility for bad code? When an engineer is negligent and a bridge collapses, they are responsible - there's a whole system of insurance around it. When a developer is negligent and user data is compromised, do they take responsibility? 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.
    - futurix 9y ago
      In your example, the cause of the collapse would be that developer drove a tank onto the bridge and didn't bother to check the weight limits beforehand. 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.
      - staticassertion 9y ago
        > In your example, the cause of the collapse would be that developer drove a tank onto the bridge and didn't bother to check the weight limits beforehand. 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.
- ksk 9y ago
  I think calling it broken design is quite unfair. I'd say to constructively criticize a programming language you'd have to bring much more to the table. You can point to specifics in the syntax, grammar, rules etc along with an argument as to why they are problems.
rb808 9y ago
> If you had 'random crashes', you probably weren't that good with C++ 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.
- iainmerrick 9y ago
  Isn't that true in any language, though? 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.
maccard 9y ago
I take it you've never made a mistake programming before then? A relatively trivial example is passing by const reference [0] While it's fairly clear in this example that you're getting a reference to a local variable, it can easily slip through if you pass something through a level or two of a function. Note there's no compiler warning for this. It also (probably) won't show up until you actually try and use St.m_x at some point, which may be in a very different place to where it was initialised. In most cases, if it shows up in an optimised build, you'll get next to 0 useful information from a debugger/stack trace. [0] https://godbolt.org/g/XTh5Mv https://godbolt.org/g/XTh5Mv
- futurix 9y ago
  My beef here is with the word 'random'. Mistakes don't make for random crashes - hard to trace perhaps, but not random.
  - stinos 9y ago
    > not random 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.
    - futurix 9y ago
      Well, yes, but it is randomness of a mistake - not randomness of the language. If you are going to shoot yourself in the foot, I guess the wound would be pretty randomly located - but that is not the fault of the gun manufacturer.
andreasgonewild 9y ago
It's definitely getting easier, but I still wouldn't even consider C++ without valgrind or similar watching over my back; and I've been writing C++ since 1995. Accessing a variant value as the wrong type, dereferencing empty smart pointers and accessing non-existing elements in collections and many many more cases will still segfault; and I don't expect that to change since it lacks that level of security by design. That being said, it's still the most pragmatic language around; the only language that allows me to choose my own level of crazy.
- farunen 9y ago
  @andreasgonewild: "It's definitely getting easier, but I still wouldn't even consider C++ without valgrind or similar watching over my back" That we still need such tools to help the compiler in 2017 tells me that programming languages haven't advance much. (moderators: yes I know, downvote and disable the account, cause any kind of disagreement is considered a micro-macro-micro-aggression, not to mention any attempt at humor).
- futurix 9y ago
  Exactly! C++ is a language where you are free to choose level of safety. None of your examples are a fault of the language - it is a fault of developer not doing necessary safety checks.
  - johannes1234321 9y ago
    The point is: some languages have capabilities to take some classes of errors out. A language with GC and heap-allocation only makes it hard to get access-after-free-style errors. Languages with bounds checks on all elements reliably crash (throw an exception) instead of showing "random" behaviour on bad reads. Of course all of that comes with a cost, but for many domains that works out ...
- iainmerrick 9y ago
  I don't find null pointers any worse in C++ than in Java or C#. Seg fault or a NullPointerException that you can't do anything useful with, take your pick. 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.

stinos 9y ago

random crashes 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.

gcp 9y ago

C++ still produces the fastest and most memory efficient programs.

rb808 9y ago
> C++ still produces the fastest and most memory efficient programs. Which is the #1 requirement for a bunch of applications. I can feel I want to go back...
nocman 9y ago
Fastest compared to what? Everything? That is definitely not true. If you were referring to Java/dotnet/python, well yeah. (I'm honestly curious to know what you meant).
- corysama 9y ago
  Definitely not formally, pedantically true. But, we aren't defending a mathematical thesis here. We're having a casual discussion. Still... let's see: Given a generic workload with equal effort put into optimizations... Should you expect C++ to be faster? 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.
  - nocman 9y ago
    My point was that the statement "C++ still produces the fastest and most memory efficient programs." is basically meaningless without any context. There are a fair number of situations where other languages can beat C++ in either or both of those metrics. "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.

ksk 9y ago

I don't quite see how the "random crashes" were not a programmer error, unless you were using a terribly unstable/buggy library. If you want performance (in the real world, utilizing code you have, libraries you purchased/wrote, etc) C++ is the way to go. Java/dotnet/python are not comparable or interchangeable with C++. And like any tool you have to work within its limitations.

oscargrouch 9y ago
If the parent used C++ in the old days, using the "Better C" paradigm im sure he will have bad memories being plaged by manual resource management. 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.