4 ms·

> What normal C++ syntax are you referring to that generates undefined behavior? If you have a function that takes two arguments and prints both, and you suppl

> What normal C++ syntax are you referring to that generates undefined behavior? If you have a function that takes two arguments and prints both, and you supply arguments like so: my_func(a++, a) You just generated undefined behavior, because the order in which the expressions inside the function call are evaluated, is not guaranteed (keep in mind the comma inside the function call is not a comma operator, which is one of I think 4 operators that actually does guarantee the evaluation order). You may say it's up to the programmer to know such rules of the programming language, however there's a lot of such rules which makes programming in C++ like walking through a minefield - yes, at some point you learned where the mines are, but you're supposed to remember about them at all times or you risk stepping on one. Another issue is how the compiler reacts to this UB - usually in a programming language you'd expect that perhaps in one version the arguments are evaluated from left to right, and in another from right to left, or perhaps in some other version it depends on current program state or some other seemingly random factors. However in C++ UB means that everything can happen, for example, the compiler may no-op the entire function call (or worse, the time-space may collapse) I consider this to actually be an advantage of C++ - there's a lot on the programmer's shoulders, but that gives more possibilities to the compilers (to optimize). I'm not an expert on C++ but that's my understanding. See also: https://news.ycombinator.com/item?id=28449461 https://news.ycombinator.com/item?id=28449461

passivate 5y ago
An expression like my_func(a++, a) is confusing on all fronts - the intention isn't clear for the compiler, for the code reviewer, for the programmer themselves when they read it 5 years from now, for the next-in-line bloke who gets handed this code to maintain it, etc. My point was about whether C++ screws you over with UB when the programmers intention can be argued to be obvious. I don't think it does. But I will stand corrected if someone can show me what they're talking about. It seems like people are making this into a discussion about C++ being a difficult language to learn - which I am not defending.
- Etherlord87 5y ago
  > My point was about whether C++ screws you over with UB when the programmers intention can be argued to be obvious. Incrementing a number is obvious and results with UB if incremented past the maximum. Since you get no guarantee whatsoever how the UB will be handled (hence the joke with the end of the space-time, or nasal demons etc.), by my understanding (that I think many experts share), it can indeed screw you up. Of course you may say a programmer should expect this to happen and so it's just a bug - every UB is. > It seems like people are making this into a discussion about C++ being a difficult language to learn I think it's more than that. Even assuming that you never caused UB yourself, you can still work on someone else's code with UB and need to debug it. So C++ is hard to learn AND use.
  - passivate 5y ago
    >if incremented past the maximum. What would be the intention to increment past the maximum? Incrementing a number infinitely is an infinite series 1+1+1[..] A programmer needs to be aware that you cannot store an infinite series in a data type like int - and this applies to any programming language. If the programmer is looking to exploit wrapping behavior then it is best not to ASSUME anything, but actually verify what promises the language provides. Its basic sanity checking, you do that before sending parameters to API, receiving parameters, during transfer of ownership of memory, etc, etc. All of this falls under basic programming - regardless of language.
    - Etherlord87 5y ago
      > A programmer needs to be aware This can be extrapolated to anything that causes UB. A programmer needs to be aware that what he does causes UB. You asked for a normal thing that is being done by a programmer that causes UB, and I think I gave a fair example. I don't want to aggressively argue a point, just wondering what exactly you want to prove here. It's not like programmers cause UB intentionally or when doing some weird stuff like code golfing. No, programmers code in C++ using standard techniques and fall victim to the UB. Another example of UB is accessing an array out of bounds. Again, you may say a programmer is expected to rationalize his code in this regard, and yet off-by-one is one of the most common categories of errors in practice.

passivate 5y ago

An expression like my_func(a++, a) is confusing on all fronts - the intention isn't clear for the compiler, for the code reviewer, for the programmer themselves when they read it 5 years from now, for the next-in-line bloke who gets handed this code to maintain it, etc. My point was about whether C++ screws you over with UB when the programmers intention can be argued to be obvious. I don't think it does. But I will stand corrected if someone can show me what they're talking about. It seems like people are making this into a discussion about C++ being a difficult language to learn - which I am not defending.

Etherlord87 5y ago
> My point was about whether C++ screws you over with UB when the programmers intention can be argued to be obvious. Incrementing a number is obvious and results with UB if incremented past the maximum. Since you get no guarantee whatsoever how the UB will be handled (hence the joke with the end of the space-time, or nasal demons etc.), by my understanding (that I think many experts share), it can indeed screw you up. Of course you may say a programmer should expect this to happen and so it's just a bug - every UB is. > It seems like people are making this into a discussion about C++ being a difficult language to learn I think it's more than that. Even assuming that you never caused UB yourself, you can still work on someone else's code with UB and need to debug it. So C++ is hard to learn AND use.
- passivate 5y ago
  >if incremented past the maximum. What would be the intention to increment past the maximum? Incrementing a number infinitely is an infinite series 1+1+1[..] A programmer needs to be aware that you cannot store an infinite series in a data type like int - and this applies to any programming language. If the programmer is looking to exploit wrapping behavior then it is best not to ASSUME anything, but actually verify what promises the language provides. Its basic sanity checking, you do that before sending parameters to API, receiving parameters, during transfer of ownership of memory, etc, etc. All of this falls under basic programming - regardless of language.
  - Etherlord87 5y ago
    > A programmer needs to be aware This can be extrapolated to anything that causes UB. A programmer needs to be aware that what he does causes UB. You asked for a normal thing that is being done by a programmer that causes UB, and I think I gave a fair example. I don't want to aggressively argue a point, just wondering what exactly you want to prove here. It's not like programmers cause UB intentionally or when doing some weird stuff like code golfing. No, programmers code in C++ using standard techniques and fall victim to the UB. Another example of UB is accessing an array out of bounds. Again, you may say a programmer is expected to rationalize his code in this regard, and yet off-by-one is one of the most common categories of errors in practice.