5 ms·

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

by futurix 9y ago

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.
    - nocman 9y ago
      "When a developer is negligent and user data is compromised, do they take responsibility? No." ^ 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.
- 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.

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.
  - nocman 9y ago
    "When a developer is negligent and user data is compromised, do they take responsibility? No." ^ 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.
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.