4 ms·

You don't get it. We're talking about completely different things. The context of the post I replied to was about C++ turning the INTENTION of the programmer in

You don't get it. We're talking about completely different things. The context of the post I replied to was about C++ turning the INTENTION of the programmer into UB. The argument isn't that you can't write bad code in C++ - you can write bad code in any language. There is no valid intention with regards to storing an infinite number series in a finite data storage unit - the example that was brought up. There is no valid intention about using a construct like my_func(a++, a) - this is a confusing construct and is not valid human-readable code. This is not normal code that is turned into UB - its bad and invalid code to begin with. In any case it doesn't seem like we're getting anywhere so I will just let you have the last word.

tialaramex 5y ago
> There is no valid intention with regards to storing an infinite number series in a finite data storage unit - the example that was brought up. No, the example that was brought up was overflow of a signed integer. Programming languages do a variety of things here, but you don't seem to be familiar with anything except C++ so let's tour briefly. BigNum languages. In these languages the limited storage size of a machine register is merely a consideration for optimisations. A programmer who is counting people on Earth, estimating global disk storage capacity in bytes or how many Hydrogen atoms there likely are in the visible Universe, needn't worry that there will be "too many" since the language has their back. There is a limit because machines are finite, but it isn't a real concern. Modern Python and many Lisps are in this family. What is this "integer" of which you speak? In these languages they chose not to worry about the integer types, or at least not to expose them to programmers. All numeric values are floating point. Tremendously large numbers can be handled, albeit they cease to have integer precision. Javascript is in this category. You can't do that. In these languages overflow is simply impossible, the compiler is doing enough type checking to figure out that your program could overflow and reject it on this basis. Some languages (including Modern Ada) can do this if you request it for specific variables, but this is how WUFFS works all the time. Overflow is an Error. In these languages overflow is a runtime error, your program must handle Overflow the same way it's obliged to handle a File Not Found error. This might involve control-flow changes like an Exception and of course you can handle that overflow badly but that's on you. Zig treats overflow as an error. Runtime failure: In these languages overflow is an immediate runtime failure. Some C and C++ compilers can be told to do this, and it is the behaviour of Rust's integer types in debug builds. Wrapping Overflow. In these languages overflow causes the number to "wrap" back past the opposite end of its range. This is pretty unintuitive, but it is at least defined. Java does this, most assembly languages do this, and Rust offers Wrapping<T> for integer types to give them this behaviour, it will also do this for integer types in release mode by default. Undefined Behaviour. This is an extraordinary response. But, it is what C and C++ chose here. So while you may say there was "no valid intention" the reality is that people simply underestimate how high they might be counting or overestimate how big these integer types are in languages like C++, and so they ran into an overflow, and that's all it takes in C++, whereas in these other languages something better happens. This is perfectly normal code, it may not be the right solution (although in some of the language classes described above it works fine), but "Undefined Behaviour" is an astonishing punishment for this oversight.

tialaramex 5y ago

> There is no valid intention with regards to storing an infinite number series in a finite data storage unit - the example that was brought up. No, the example that was brought up was overflow of a signed integer. Programming languages do a variety of things here, but you don't seem to be familiar with anything except C++ so let's tour briefly. BigNum languages. In these languages the limited storage size of a machine register is merely a consideration for optimisations. A programmer who is counting people on Earth, estimating global disk storage capacity in bytes or how many Hydrogen atoms there likely are in the visible Universe, needn't worry that there will be "too many" since the language has their back. There is a limit because machines are finite, but it isn't a real concern. Modern Python and many Lisps are in this family. What is this "integer" of which you speak? In these languages they chose not to worry about the integer types, or at least not to expose them to programmers. All numeric values are floating point. Tremendously large numbers can be handled, albeit they cease to have integer precision. Javascript is in this category. You can't do that. In these languages overflow is simply impossible, the compiler is doing enough type checking to figure out that your program could overflow and reject it on this basis. Some languages (including Modern Ada) can do this if you request it for specific variables, but this is how WUFFS works all the time. Overflow is an Error. In these languages overflow is a runtime error, your program must handle Overflow the same way it's obliged to handle a File Not Found error. This might involve control-flow changes like an Exception and of course you can handle that overflow badly but that's on you. Zig treats overflow as an error. Runtime failure: In these languages overflow is an immediate runtime failure. Some C and C++ compilers can be told to do this, and it is the behaviour of Rust's integer types in debug builds. Wrapping Overflow. In these languages overflow causes the number to "wrap" back past the opposite end of its range. This is pretty unintuitive, but it is at least defined. Java does this, most assembly languages do this, and Rust offers Wrapping<T> for integer types to give them this behaviour, it will also do this for integer types in release mode by default. Undefined Behaviour. This is an extraordinary response. But, it is what C and C++ chose here. So while you may say there was "no valid intention" the reality is that people simply underestimate how high they might be counting or overestimate how big these integer types are in languages like C++, and so they ran into an overflow, and that's all it takes in C++, whereas in these other languages something better happens. This is perfectly normal code, it may not be the right solution (although in some of the language classes described above it works fine), but "Undefined Behaviour" is an astonishing punishment for this oversight.