gpd wrote:
Yes, this is very important! There is lots of code around that started breaking when compilers started doing type based alias analysis (practically all code that relied on undefined reinterpret casts which were "practically safe"). Just because it works with current compilers, It doesn't means it won't break with future ones when they'll get smarter and smarter.
That might have been true some years ago. Current compilers are pretty aggressive when optimizing and will rely on every dark corner of the specs as possible. And will do more so in the future.
Well, let's think about this critically. If the compiler started doing optimizations that caused code that casts between base class and derived class and back again to function incorrectly because the compiler decided the spec told it that those were different types and couldn't be the same pointer address what percentage of real C++ applications would be broken? Would it be worse than when the compiler started assuming a pointer to a float couldn't be the same address as a pointer to an int? I pointed out that the banana has no wires coming out of it, yet am being told that we might one day invent wireless transmission of electricity. Even if we did I'm not convinced it would be used to electrify this particular banana. We can always tell the compiler guys "hey, I'm eating this banana, please don't electrify it." Like I said before, if the compiler did what you suggest they would just end up rolling it back because it would break too many things. People are doing egregious things with casting completely unrelated types back and forth all the time. I see it in my work and I do try to tell them they're playing with fire (because it's error prone, not because of compiler concerns) but they can make it work with enough trial and error and that is how real applications work, unfortunately. Luke