Well, it does unstructured imperative, structured imperative, and OOP imperative!
Except if you count template programming, because that one is pure functional, but only runs at compile time.
- There’s at least an ugly library to do it in C++
- There might be support baked directly into the language
- Or you could do it in Lisp, but that would be too easy
Here's an article on the topic: https://cryptoservices.github.io/fde/2018/11/30/undefined-be...
Most compilers will do something like "treat the bits like they represent a float, even though they mean something else when they're treated as an int."
But the language spec says the compiler is allowed to send an email to Bjarne Stroustrup with your home address so he can come over and personally set your computer on fire.
More seriously, the typical response to undefined behavior is for the compiler to optimize out whatever code may trigger it. It is great for performance and one of the reasons C and C++ often top the charts, but it may lead to weird bugs that depend on the optimization level.
For the union case, the compiler could completely remove the code that reads the float: because it is UB, it is something you shouldn't do, so it considers that you will never do it, so it can just remove the code. In the end your conversion function may do nothing at all (very optimized!). In practice, because it is so common, even though it is UB, it will usually do what you want it to do.
Literal lol... this is not an argument in favor of C++.
Actually, strike that: I'm not sure if it's true or not (though I suspect it is), but it doesn't actually matter. What I'm really getting at here is that there is nothing in Rust that behaves so confusingly or ambiguously as what's described in this article. If you're writing Rust, you'll never have to remember these sorts of rules and how they are going to be applied to your code.
I do agree that reading someone else's Rust can be a challenge, if they're using Rust's type system to its fullest, and you're (quite reasonably and understandably) not up to speed on the entirety of it. And that is a problem, agreed; though, at least, fortunately it's not a problem of ambiguity, but more of a learning-curve issue.
But I have never been writing Rust and have been confused about what the code I'm writing might do, never had to consult and puzzle out some obscure documentation in order to ensure that the code I was writing was going to do what I expected it to do. C++ falls so incredibly flat in this department, and that's why I avoid using it like the plague.
You have "C with classes" that coexist with the "modern" way, full of smart pointers and functional programming. It is popular in embedded systems, video games, servers, and GUIs (mostly Qt). And if you look at the code, it is as if it was a different language, because the requirements are all very different. Embedded system need low level hardware access, video games are all about performance, servers want safety, and GUIs want flexibility.
There are less awful alternative to C++. For example C on one end of the spectrum and Rust on the other end. But none of them cover every C++ use case.