7 ms·

Comments like this are a dime a dozen on HN. Every time I see one, I wonder what horror raises such ire. I like C++ and use it voluntarily for my research. How

Comments like this are a dime a dozen on HN. Every time I see one, I wonder what horror raises such ire. I like C++ and use it voluntarily for my research. How did it bite you?

titzer 5y ago
I've been programming in C++, sometimes heavily, since 1998. I worked on V8 for almost 7 years. Those were some of my worst debugging experiences (truth be told, usually at the mercy of my own mistakes in the JIT there.). They say that you can shoot yourself in the foot in C, and blow your leg off in C++. And that's because UB can mean the compiler's dirty tricks all become part of the mystery as to why exactly a program crashed the way it did. I used to ask as an interview question, "You have a C program that crashes. You add a printf and it stops crashing. Why?" There is no right answer...the list is a mile long of things that could be wrong. Obviously it's a bug in my program, in my code. But damned if every tool in the whole chain is going to be so damn unhelpful in finding it. They tell me it's my fault but they proceed to puke their internals at me and let me try to figure it out! Ugggggh!!!! So I screw up my program, but BAM! Suddenly I am thrust into a complete alternative reality of machine implementation details, a metric asston of low-level irrelevant information...and somewhere in there are clues only I can work out. It was the optimizer! Because my program triggered UB, some insanely complex chain of compiler reasoning led it to the mess that is there now. I am forced to debug the actual machine code. I must. Or its tendrils, raw addresses spewed by a debugger, trying to picture in my head how the fuck these two datastructures got overlapped in memory wrong but it only shows up in optimized code, but manifests in a super-misleading crash. And it was because a field was uninitialized and for some other damn reason it was just working before, like the memory was already zero'd by accident, because it was reusing some specific pattern of deallocated memory, meaning that something was just kinda magically perched on top of it, hiding that bug....You realize it's a very fragile stack of stones. And then you realize the whole tower is at risk. The code actually has bugs. Right now. Bugs you haven't found yet. Bugs your idiot savant super-intelligent mega-optimizing compiler is recruiting the sum total of hundreds or perhaps thousands of smart humans who think of new ways to make the code go faster, but never bother to reason about undefined behavior, leaving it entirely questionable as to future results of the program you have written today, or happen to be ever-so-unhappily in charge of, but...but...is full of bugs. UB bugs. Like, the worst kind. In the limit, you must fear that a completely super-intelligent compiler would at this point conclude that all C/C++ code having bugs is wrong and will technically replace it with a no-op. Suddenly computers stop booting after a software update because the AI optimized away the kernel to essentially the minimal thing that can pass the compiler's unit test suite, but otherwise is a no-op, mass hysteria, cats and dogs living together. Ok, maybe I made that last part up. But yeah, this UB thing is really bad. I feel like I am taking crazy pills, because to me the experience of working with C++ is like being a grunt stuck on a 2 mile-long digging machine that has all the controls set to "BECAUSE FAST" and the only answer to "why all this?" is the computer-programming-equivalent of a kick in the nuts. I seriously hate that experience. I mean seriously, as a compiler person, I love looking at machine code. But that's no way to debug programs. It sucks. Arguably the absolute first job of a programming language is to try to raise the abstraction level. But we can't. Because this stupid language pukes the machine at us. We are fundamentally incapable of raising the abstraction level with C/C++ and drown in a just total cesspool of wasted human effort.
- carlmr 5y ago
  What's worse. C and C++ are the de facto standard languages for safety critical embedded systems. Aerospace/defense laid the ground work for something better with Ada/SPARK, but the rest of the safety critical industries don't seem to care. At least now the AUTOSAR committee is taking a look at Rust, which gives me some hope for some sanity in the future here.
  - johnisgood 5y ago
    Yep. Ada/SPARK would be a much better choice over both C and Rust. People turning to Rust for safety really ought to look into Ada's SPARK subset and its capabilities. If it is truly safety they are looking after, Ada/SPARK is the best option. Ada by itself has a really great type system. You want the length of an array? You can use `X'Length`. You can define types using ranges and so forth. I wish more languages implemented such things.
    - carlmr 5y ago
      I do think SPARK is the best in terms of safety, but Rust also provides way better safety mechanisms than almost any other language, so I wouldn't discount it so quickly. Also Rust, I think, has much better developer ergonomics (outside of the delta types which I would really like to have everywhere), and to improve on the status quo we need something safer, but also something people will use. In the same vein it's useful that Rust is a bit trendy now, since you'll need a lot of people to advocate for this kind of change successfully. The worst outcome is sticking with C and C++ any longer. Perfect being the enemy of good shouldn't keep us here.
      - titzer 5y ago
        Slap a new coat of paint on Ada; put in curly braces and 'var', and you got something!
- pjmlp 5y ago
  Which is why having been exposed to system programing languages other than C and C++ is an eye opener on how things could look like with a different mindset.

Comments like this are a dime a dozen on HN. Every time I see one, I wonder what horror raises such ire. I like C++ and use it voluntarily for my research. How did it bite you?

titzer 5y ago

I've been programming in C++, sometimes heavily, since 1998. I worked on V8 for almost 7 years. Those were some of my worst debugging experiences (truth be told, usually at the mercy of my own mistakes in the JIT there.). They say that you can shoot yourself in the foot in C, and blow your leg off in C++. And that's because UB can mean the compiler's dirty tricks all become part of the mystery as to why exactly a program crashed the way it did. I used to ask as an interview question, "You have a C program that crashes. You add a printf and it stops crashing. Why?" There is no right answer...the list is a mile long of things that could be wrong. Obviously it's a bug in my program, in my code. But damned if every tool in the whole chain is going to be so damn unhelpful in finding it. They tell me it's my fault but they proceed to puke their internals at me and let me try to figure it out! Ugggggh!!!! So I screw up my program, but BAM! Suddenly I am thrust into a complete alternative reality of machine implementation details, a metric asston of low-level irrelevant information...and somewhere in there are clues only I can work out. It was the optimizer! Because my program triggered UB, some insanely complex chain of compiler reasoning led it to the mess that is there now. I am forced to debug the actual machine code. I must. Or its tendrils, raw addresses spewed by a debugger, trying to picture in my head how the fuck these two datastructures got overlapped in memory wrong but it only shows up in optimized code, but manifests in a super-misleading crash. And it was because a field was uninitialized and for some other damn reason it was just working before, like the memory was already zero'd by accident, because it was reusing some specific pattern of deallocated memory, meaning that something was just kinda magically perched on top of it, hiding that bug....You realize it's a very fragile stack of stones. And then you realize the whole tower is at risk. The code actually has bugs. Right now. Bugs you haven't found yet. Bugs your idiot savant super-intelligent mega-optimizing compiler is recruiting the sum total of hundreds or perhaps thousands of smart humans who think of new ways to make the code go faster, but never bother to reason about undefined behavior, leaving it entirely questionable as to future results of the program you have written today, or happen to be ever-so-unhappily in charge of, but...but...is full of bugs. UB bugs. Like, the worst kind. In the limit, you must fear that a completely super-intelligent compiler would at this point conclude that all C/C++ code having bugs is wrong and will technically replace it with a no-op. Suddenly computers stop booting after a software update because the AI optimized away the kernel to essentially the minimal thing that can pass the compiler's unit test suite, but otherwise is a no-op, mass hysteria, cats and dogs living together. Ok, maybe I made that last part up. But yeah, this UB thing is really bad. I feel like I am taking crazy pills, because to me the experience of working with C++ is like being a grunt stuck on a 2 mile-long digging machine that has all the controls set to "BECAUSE FAST" and the only answer to "why all this?" is the computer-programming-equivalent of a kick in the nuts. I seriously hate that experience. I mean seriously, as a compiler person, I love looking at machine code. But that's no way to debug programs. It sucks. Arguably the absolute first job of a programming language is to try to raise the abstraction level. But we can't. Because this stupid language pukes the machine at us. We are fundamentally incapable of raising the abstraction level with C/C++ and drown in a just total cesspool of wasted human effort.

carlmr 5y ago
What's worse. C and C++ are the de facto standard languages for safety critical embedded systems. Aerospace/defense laid the ground work for something better with Ada/SPARK, but the rest of the safety critical industries don't seem to care. At least now the AUTOSAR committee is taking a look at Rust, which gives me some hope for some sanity in the future here.
- johnisgood 5y ago
  Yep. Ada/SPARK would be a much better choice over both C and Rust. People turning to Rust for safety really ought to look into Ada's SPARK subset and its capabilities. If it is truly safety they are looking after, Ada/SPARK is the best option. Ada by itself has a really great type system. You want the length of an array? You can use `X'Length`. You can define types using ranges and so forth. I wish more languages implemented such things.
  - carlmr 5y ago
    I do think SPARK is the best in terms of safety, but Rust also provides way better safety mechanisms than almost any other language, so I wouldn't discount it so quickly. Also Rust, I think, has much better developer ergonomics (outside of the delta types which I would really like to have everywhere), and to improve on the status quo we need something safer, but also something people will use. In the same vein it's useful that Rust is a bit trendy now, since you'll need a lot of people to advocate for this kind of change successfully. The worst outcome is sticking with C and C++ any longer. Perfect being the enemy of good shouldn't keep us here.
    - titzer 5y ago
      Slap a new coat of paint on Ada; put in curly braces and 'var', and you got something!
pjmlp 5y ago
Which is why having been exposed to system programing languages other than C and C++ is an eye opener on how things could look like with a different mindset.