Re: [boost] [GTL] - geometric template library - determininginterest

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2007-10-11 13:06:28

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