9 ms·

And therein lies a major problem with c and c++ compilers: It's effectively impossible to write bug free code. Bugs in c and c++ usually trigger undefined beha

And therein lies a major problem with c and c++ compilers: It's effectively impossible to write bug free code. Bugs in c and c++ usually trigger undefined behavior. It is therefore impossible to write a conforming program, which makes any guarantees in the spec meaningless. I've hit heisenbugs like these that only trigger when optimized, and resist write(), out(), fflush(), etc and it's infuriating. Or even worse: programs that no longer work when compiled on a newer compiler. With other languages, you are at least spared from this kind of code decay. But everyone's writing compilers to the spec so tough :/

nwmcsween 8y ago
That's actually good your code breaks using new compilers as it means the code is bogus anyways. The alternatives to UB is either a strict spec that will be dog slow on $arch or abstract away everything and make it complex.
- saagarjha 8y ago
  This isn't necessarily true. Many compiled languages these days have a strong specification that guarantees a lack of undefined behavior for the vast majority of code, yet remain relatively performant–think Swift, Rust, and the like.
- pjmlp 8y ago
  Being dog slow is very much dependent on the use case. Yes it will be slower than taking every shortcut in the name of performance. What really matters is, does the execution speed and memory footprint meat the requirements? If the user is happy to get their data in 100ms, with a requirement of 300ms max, getting it in 10ms is hardly an advantage.
  - jjnoakes 8y ago
    If you can deliver responses 10x faster than required, you can scale with 10x fewer resources (or at least presumably some factor of fewer resources) and still stay within the user requirements. I'd say that's a nice advantage.
    - pjmlp 8y ago
      Not everyone is going to be the next Google, Facebook, Crytech, EA, ... There are better ways to waste money than spending it on YAGNI features.
      - jstimpfle 8y ago
        Consider Parkinson's law... Compare git to mercurial... Consider how many successful Java command line programs are there?
        pjmlp 8y ago
        There are plenty of them at the enterprise level. Just a couple of months ago I re-wrote several Korn shell scripts doing ETL related tasks into a couple of saner Java CLI programs at customer request.
        jstimpfle 8y ago
        And the responsiveness is good? Isn't there always this terrible startup lag? Could we rewrite the C implementation of e.g. git in Java to get a program that is just as fast (e.g., instantaneous response for most operations)?
        pjmlp 8y ago
        Surely, you know that there are native code compilers for Java, right?
        jstimpfle 8y ago
        Is this practical? What are the limitations? Is this Java spirit? Why doesn't everybody use it? What does this do about startup time? My initial point in the meantime was only that performance does matter. And that for some reason I cannot recall any (open source or free software) CLI programs written in Java from the top of my head. While there are free Java implementations easily available no?
  - MauranKilom 8y ago
    Correct, it depends on the use case. Nobody is saying you should write everything in C++. But there is plenty of software that actually uses your CPU for data processing where speed is absolutely crucial. If you know that every second (or 100 ms) saved in every functionality your software offers will eventually matter, would you still choose the more pessimistic performance guarantee? Did you know (at the point where the entire architecture was chosen) that you will get 100 ms with a safer language? What if you got 1000 ms and C++ got 100 ms?
    - pjmlp 8y ago
      Thing is, C and C++ aren't the only language with those capabilities, e.g. CPU for data processing. What to live on the danger zone and disable bounds checking on e.g. Turbo Pascal? Surround the critical performance code path with {$R-} and {$R+}, while enjoying safe bounds checking everywhere else.
banachtarski 8y ago
This is a myopic viewpoint. Undefined behavior is critical for code that needs to be fast. The premise of languages like C and C++ is that the airgap between the language's abstract execution and memory model and the hardware's is thin to non-existent. *(edit accidentally submitted early) In this case, the UB is due to the compiler's ability to reorder statements. This is such a fundamental optimization that I can't imagine you're really suggesting that a language without this optimization capability is a "problem." Rearranging instructions is critical for pretty much any superscalar processor (which all the major ones are), and I hate to imagine the hell I'd be in if I had to figure out the optimal load/store ordering myself.
- saagarjha 8y ago
  > In this case, the UB is due to the compiler's ability to reorder statements. No, the undefined behavior arises because dividing by zero is undefined. Languages wishing avoiding this particular bug can make division by zero defined to trap or have some sort of guaranteed behavior, after which the compiler is required to not reorder those statements. In this case reordering the instructions is legal because having undefined behavior in your program makes literally anything the compiler does legal.
  - banachtarski 8y ago
    My point still stands in that I don't want the compiler to check for division by zero if I don't ask it to.
    - saagarjha 8y ago
      Sure, then use C or C++ and check for it yourself. But if you mess up your program is invalid, so there's that. If you don't like that, write your own assembly by hand to convert this to implementation-defined behavior instead of undefined behavior.
    - deleted 8y ago
      [deleted]
- 8y ago
otabdeveloper2 8y ago
"Undefined behavior" doesn't mean "buggy". It simply means stuff that's CPU-specific or compiler-specific. C++ has a standard, unlike languages like Rust or Python. This is a good thing, because compiler-specific crap doesn't magically go away if you avoid standards and just declare one implementation as a "reference".
- saagarjha 8y ago
  > "Undefined behavior" doesn't mean "buggy". It simply means stuff that's CPU-specific or compiler-specific. Yes, it does. The behavior you are describing is "implementation specific", and it is ok to have this in your program provided you know what your implementation will do. It is illegal to have any undefined behavior in a well-formed C/C++ program.
  - otabdeveloper2 8y ago
    When people talk of UB in C++ they always mean "implementation specific".
    - saagarjha 8y ago
      No, they don’t. These are separate concepts with different behavior. “Undefined behavior” is illegal to have in C/C++ programs and includes things like division by zero and out-of-bounds array access. “Implementation specific” behavior is legal but allowed to differ, such as querying the size of an int.
    - esrauch 8y ago
      You really don't need to go very far to get into UB instead of implementation defined: signed int overflow is already UB and the program is permitted to do literally anything if you ever accidentally make one of your ints too large.
  - tom_ 8y ago
    The standard doesn't defined well-formedness, nor does it consider undefined behaviour illegal necessarily. It simply has nothing to say about what happens when undefined behaviour is invoked. And it is OK to invoke it if you know what your implementation will do. The standard even gives documenting the behaviour as an option. (I wonder how many people worry about supplying clang a file that doesn't end in a new line? That is undefined behaviour, and yet you know exactly what's going to happen: you'll get a warning, if compilation continues the code will build as if the new line were there, and clang won't delete your source file, even though it would be perfectly within its rights to.)
shin_lao 8y ago
| It's effectively impossible to write bug free code. What does that even mean? It's impossible to have bug free code in any language. Bug in the libraries, the compiler, in the OS, in the hardware...

nwmcsween 8y ago

That's actually good your code breaks using new compilers as it means the code is bogus anyways. The alternatives to UB is either a strict spec that will be dog slow on $arch or abstract away everything and make it complex.

saagarjha 8y ago
This isn't necessarily true. Many compiled languages these days have a strong specification that guarantees a lack of undefined behavior for the vast majority of code, yet remain relatively performant–think Swift, Rust, and the like.
pjmlp 8y ago
Being dog slow is very much dependent on the use case. Yes it will be slower than taking every shortcut in the name of performance. What really matters is, does the execution speed and memory footprint meat the requirements? If the user is happy to get their data in 100ms, with a requirement of 300ms max, getting it in 10ms is hardly an advantage.
- jjnoakes 8y ago
  If you can deliver responses 10x faster than required, you can scale with 10x fewer resources (or at least presumably some factor of fewer resources) and still stay within the user requirements. I'd say that's a nice advantage.
  - pjmlp 8y ago
    Not everyone is going to be the next Google, Facebook, Crytech, EA, ... There are better ways to waste money than spending it on YAGNI features.
    - jstimpfle 8y ago
      Consider Parkinson's law... Compare git to mercurial... Consider how many successful Java command line programs are there?
      - pjmlp 8y ago
        There are plenty of them at the enterprise level. Just a couple of months ago I re-wrote several Korn shell scripts doing ETL related tasks into a couple of saner Java CLI programs at customer request.
        jstimpfle 8y ago
        And the responsiveness is good? Isn't there always this terrible startup lag? Could we rewrite the C implementation of e.g. git in Java to get a program that is just as fast (e.g., instantaneous response for most operations)?
        pjmlp 8y ago
        Surely, you know that there are native code compilers for Java, right?
        jstimpfle 8y ago
        Is this practical? What are the limitations? Is this Java spirit? Why doesn't everybody use it? What does this do about startup time? My initial point in the meantime was only that performance does matter. And that for some reason I cannot recall any (open source or free software) CLI programs written in Java from the top of my head. While there are free Java implementations easily available no?
- MauranKilom 8y ago
  Correct, it depends on the use case. Nobody is saying you should write everything in C++. But there is plenty of software that actually uses your CPU for data processing where speed is absolutely crucial. If you know that every second (or 100 ms) saved in every functionality your software offers will eventually matter, would you still choose the more pessimistic performance guarantee? Did you know (at the point where the entire architecture was chosen) that you will get 100 ms with a safer language? What if you got 1000 ms and C++ got 100 ms?
  - pjmlp 8y ago
    Thing is, C and C++ aren't the only language with those capabilities, e.g. CPU for data processing. What to live on the danger zone and disable bounds checking on e.g. Turbo Pascal? Surround the critical performance code path with {$R-} and {$R+}, while enjoying safe bounds checking everywhere else.

banachtarski 8y ago

This is a myopic viewpoint. Undefined behavior is critical for code that needs to be fast. The premise of languages like C and C++ is that the airgap between the language's abstract execution and memory model and the hardware's is thin to non-existent. *(edit accidentally submitted early) In this case, the UB is due to the compiler's ability to reorder statements. This is such a fundamental optimization that I can't imagine you're really suggesting that a language without this optimization capability is a "problem." Rearranging instructions is critical for pretty much any superscalar processor (which all the major ones are), and I hate to imagine the hell I'd be in if I had to figure out the optimal load/store ordering myself.

saagarjha 8y ago
> In this case, the UB is due to the compiler's ability to reorder statements. No, the undefined behavior arises because dividing by zero is undefined. Languages wishing avoiding this particular bug can make division by zero defined to trap or have some sort of guaranteed behavior, after which the compiler is required to not reorder those statements. In this case reordering the instructions is legal because having undefined behavior in your program makes literally anything the compiler does legal.
- banachtarski 8y ago
  My point still stands in that I don't want the compiler to check for division by zero if I don't ask it to.
  - saagarjha 8y ago
    Sure, then use C or C++ and check for it yourself. But if you mess up your program is invalid, so there's that. If you don't like that, write your own assembly by hand to convert this to implementation-defined behavior instead of undefined behavior.
  - deleted 8y ago
    [deleted]
8y ago

otabdeveloper2 8y ago

"Undefined behavior" doesn't mean "buggy". It simply means stuff that's CPU-specific or compiler-specific. C++ has a standard, unlike languages like Rust or Python. This is a good thing, because compiler-specific crap doesn't magically go away if you avoid standards and just declare one implementation as a "reference".

saagarjha 8y ago
> "Undefined behavior" doesn't mean "buggy". It simply means stuff that's CPU-specific or compiler-specific. Yes, it does. The behavior you are describing is "implementation specific", and it is ok to have this in your program provided you know what your implementation will do. It is illegal to have any undefined behavior in a well-formed C/C++ program.
- otabdeveloper2 8y ago
  When people talk of UB in C++ they always mean "implementation specific".
  - saagarjha 8y ago
    No, they don’t. These are separate concepts with different behavior. “Undefined behavior” is illegal to have in C/C++ programs and includes things like division by zero and out-of-bounds array access. “Implementation specific” behavior is legal but allowed to differ, such as querying the size of an int.
  - esrauch 8y ago
    You really don't need to go very far to get into UB instead of implementation defined: signed int overflow is already UB and the program is permitted to do literally anything if you ever accidentally make one of your ints too large.
- tom_ 8y ago
  The standard doesn't defined well-formedness, nor does it consider undefined behaviour illegal necessarily. It simply has nothing to say about what happens when undefined behaviour is invoked. And it is OK to invoke it if you know what your implementation will do. The standard even gives documenting the behaviour as an option. (I wonder how many people worry about supplying clang a file that doesn't end in a new line? That is undefined behaviour, and yet you know exactly what's going to happen: you'll get a warning, if compilation continues the code will build as if the new line were there, and clang won't delete your source file, even though it would be perfectly within its rights to.)

shin_lao 8y ago

| It's effectively impossible to write bug free code. What does that even mean? It's impossible to have bug free code in any language. Bug in the libraries, the compiler, in the OS, in the hardware...