Is undefined behavior still a thing with modern languages?
Is undefined behavior still a thing with modern languages?
Zachary Parker
Other urls found in this thread:
blog.llvm.org
youtube.com
twitter.com
Juan Scott
no
Brody Sanchez
do you really think modern developers can handle such intimidating oppressive concepts?
Caleb Clark
>UB simplifies the compiler's job
True
>allows the compiler to generate very efficient code
Mixed truth.
Nathaniel Reed
why do you waste so much time being angry about stuff?
Luis Cruz
It's 99% true. Undefined behaviour lets the compiler *choose* what to do in certain situations including but not limited to immediately terminating the program or doing the opposite of what may have been intended. So the compiler writer has the choice to optimize the code extremely aggressively assuming, for instance, that any path/data that causes UB doesn't exist.
But UB can be completely ignored, there's no situation where UB forces you to make code slower, you can pretty much ignore it for optimizations so it shouldn't have a negative inherent effect. Obviously there are some cases where the opportunity for UB optimizations will make an over-zealous compiler do worse, but this is rare and it's where I concede that 1%.
Carson Price
>he satirises people who think dumb things so he must be emotionally angry at them
Kayden Brooks
The most efficient compilers is for very well-defined architectures/runtimes where there can be absolutely no ambiguity.
UB doesn't enable optimizations, it enables portability. Anything portable can not be as efficient as non-portable code.
Wyatt Adams
>and ended I trying to make a living selling fantasy novels
I'm gonna guess that isn't going too well.
Ian Miller
>UB doesn't enable optimizations, it enables portability.
It does both! You can't say it doesn't enable optimizations that's just idiotic.
>Anything portable can not be as efficient as non-portable code.
I just explained how UB lets a compiler have the choice between doing something expected, and not. So in theory the compiler can *choose* to do the more efficient thing. What you're saying is just logically completely wrong you better explain it a bit better than "Anything portable can not be as efficient".
Anthony Gutierrez
No it's not
Easton Jenkins
>It does both!
That's an oxymoron.
>You can't say it doesn't enable optimizations that's just idiotic.
It doesn't. You can not rely on UB for optimizations, because it is UB.
>I just explained how UB lets a compiler have the choice between doing something expected, and not
Neither of these can be considered optimizations.
>So in theory the compiler can *choose* to do the more efficient thing.
You can not rely on this. It may very well just make demons fly out your nose or open up Emacs and play a tower of Hanoi simulation.
>What you're saying is just logically completely wrong you better explain it a bit better than "Anything portable can not be as efficient".
Optimisations rely on the functionality of the underlying architecture and/or runtime. The reason why things in the C standard are allowed to be undefined is to make it simpler for the language implementation to NOT consider the underlying runtime/architecture. UB is not a doorway for optimisations, it is a copout to avoid making assumptions.
This is why Java or other JVM languages can in very (very, very) specific use cases be faster than C, because you can rely on architecture specifics that a well-defined Java VM provides.
Connor Young
>It doesn't. You can not rely on UB for optimizations, because it is UB.
I think you're both talking about different things here, he means optimizing in terms of the compiler optimizing code, not the programmer optimizing the code he gives to the compiler.
Levi Diaz
Less assumptions about code are possible with UB.
It's true that there is no guarantee optimizations will happen with any compiler (not just C btw).
But with less assumptions you have more wiggle room to perform optimizations, yes even ones that rely on "architecture specifics".
What aren't you getting? Why do you think enabling optimizations *and* portability is an oxymoron?
Grayson Peterson
>I think you're both talking about different things here, he means optimizing in terms of the compiler optimizing code
This doesn't make any sense. If it is undefined, then it can not by definition be an optimisation.
The compiler can not possibly correctly interpret the intention of the programmer, and therefore it can not know if it is optimising it or simply making everything worse. This is not what anyone would call optimisation, this is merely doing something random.
>Less assumptions about code are possible with UB.
Yes
>But with less assumptions you have more wiggle room to perform optimizations, yes even ones that rely on "architecture specifics".
See my answer above. It isn't an optimisation, it's simply producing a random output.
>Why do you think enabling optimizations *and* portability is an oxymoron?
Because they are, for the reasons I have explained. Runtime optimisation, by definition, are only possible when the compiler or programmer can make certain assumptions on the runtime.
Joshua Reyes
Read a book, retard, undefined behavior is one of the reason why C is blazing fast.
Joshua Roberts
No, it is "blazing fast" because it is a portable assembly with minimal runtime overhead. It's only within the last decade and half that C compilers have implemented architectural support that finally makes C compilers better at producing fast code than FORTRAN compilers for example. This is the reason why many, especially physicists, still cling to FORTRAN.
Matthew Murphy
>Read a book, retard
I would suggest you do the same. UB allows C to be implemented on everything from complex processors to toaster MCUs.
I would suggest Compilers: Principles, Techniques & Tools
Jacob Ward
blog.llvm.org
I think I'm going to trust a compiler dev instead of any of you.
Ian Lewis
>I think I'm going to trust a compiler dev instead of any of you.
You can actually still find my name under LLVM contributors (I just checked).
Brody Stewart
big portion of UB is reasonable if the goal is portability to various archs and from difference between CPU instructions constrains and mathematical model
but hell implementation-defined behavior is the fucking worst
Brody Parker
Fixing pronouns?
William Jenkins
const correctness is important in C++ :^)
Chase Bennett
youtube.com
notably 39:16
William Gomez
>This doesn't make any sense. If it is undefined, then it can not by definition be an optimisation.
Oh my fucking god, you have no reading comprehension at all.
Jaxon Flores
>You can not rely on UB for optimizations, because it is UB.
It's not you the programmer who relies on UB for optimizations, it's the compiler. It can assume that you aren't feeding the program data that will actually cause UB, such as signed arithmetic overflow or using uninitialized variables.