3 ms·

Yeah, I know what UB is, and that's why I'm saying that this is not UB. Have you even read what I wrote?

tialaramex 5y ago
I recommend stepping back for a moment and asking yourself: Why is it that you, the person who believe they "know what UB is" and is sure "this is not UB" did not understand what's going on here, while the other people reading who explained why it's UB have understood exactly what's going on ? Doesn't it seem most likely that you in fact do not understand Undefined Behaviour and didn't understand what's going on ?
- inshadows 5y ago
  I don't think you understand UB, because clearly, this is not UB. But I congratulate you. You have enough knowledge to engage in Internet discussions involving fancy names without understanding underlying concepts. Hint: 1) Read my original post. 2) Contemplate whether the compiler is removing anything in this instance.
  - tialaramex 5y ago
    > Read my original post. Your original post has some questions. This is good, when you don't understand the world, you can ask questions and other people can help you to understand. Let's look at the questions: > Where is the undefined behavior? Using an Optional's value when it doesn't have one is Undefined. Specifically in this case use of the arrow operator on key_data_ is undefined. > how can the compiler infer that has_value() call has any relation to key_data_ non-NULL-ness? The compiler is allowed to use almost whatever means it wants to infer this type of relationship. For example if the Optional has_value() checks a member pointer isn't nullptr, and the arrow operator overload uses that pointer, the compiler can infer that if the arrow operator was used then has_value() is true. At this point you had exciting opportunities to learn stuff you didn't understand about C++ Unfortunately, you also insisted upon some claims that are false, perhaps things you wrongly believed about C++ already that now came up against a fact about the world which seemed to prove them wrong. In particular: > But that undefined behavior happens at runtime, i.e. compile time UB is not invoked This isn't a thing. If you learned it somewhere, the source was wrong, if you've instead developed this as some sort of intuition about how C++ works, dismiss this understanding, it will continue to mislead you if retained. Undefined Behaviour is a claim about the entire program which is useful to the compiler since its purpose is to transform the program. If it was Undefined before the transformation, it will still be Undefined afterwards, no matter what the transformation did, so you didn't break anything with your transformation. > the statements are kept without any optimizations. No. The compiler is free to use what it knows to optimize this code. Undefined Behaviour frees it up to optimize here a whole lot more than otherwise. In particular it needn't worry about scenarios where key_data.has_value() is false, those have Undefined Behaviour, so nothing it could do is wrong.

I recommend stepping back for a moment and asking yourself: Why is it that you, the person who believe they "know what UB is" and is sure "this is not UB" did not understand what's going on here, while the other people reading who explained why it's UB have understood exactly what's going on ? Doesn't it seem most likely that you in fact do not understand Undefined Behaviour and didn't understand what's going on ?

inshadows 5y ago
I don't think you understand UB, because clearly, this is not UB. But I congratulate you. You have enough knowledge to engage in Internet discussions involving fancy names without understanding underlying concepts. Hint: 1) Read my original post. 2) Contemplate whether the compiler is removing anything in this instance.
- tialaramex 5y ago
  > Read my original post. Your original post has some questions. This is good, when you don't understand the world, you can ask questions and other people can help you to understand. Let's look at the questions: > Where is the undefined behavior? Using an Optional's value when it doesn't have one is Undefined. Specifically in this case use of the arrow operator on key_data_ is undefined. > how can the compiler infer that has_value() call has any relation to key_data_ non-NULL-ness? The compiler is allowed to use almost whatever means it wants to infer this type of relationship. For example if the Optional has_value() checks a member pointer isn't nullptr, and the arrow operator overload uses that pointer, the compiler can infer that if the arrow operator was used then has_value() is true. At this point you had exciting opportunities to learn stuff you didn't understand about C++ Unfortunately, you also insisted upon some claims that are false, perhaps things you wrongly believed about C++ already that now came up against a fact about the world which seemed to prove them wrong. In particular: > But that undefined behavior happens at runtime, i.e. compile time UB is not invoked This isn't a thing. If you learned it somewhere, the source was wrong, if you've instead developed this as some sort of intuition about how C++ works, dismiss this understanding, it will continue to mislead you if retained. Undefined Behaviour is a claim about the entire program which is useful to the compiler since its purpose is to transform the program. If it was Undefined before the transformation, it will still be Undefined afterwards, no matter what the transformation did, so you didn't break anything with your transformation. > the statements are kept without any optimizations. No. The compiler is free to use what it knows to optimize this code. Undefined Behaviour frees it up to optimize here a whole lot more than otherwise. In particular it needn't worry about scenarios where key_data.has_value() is false, those have Undefined Behaviour, so nothing it could do is wrong.