From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-10-11 13:33:12
On 10/11/07, Simonson, Lucanus J <lucanus.j.simonson_at_[hidden]> wrote:
> gpd wrote:
> > [...]
> >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?
A lot. That's why many projects are stuck with obsolete compilers or
with suboptimal optimization options.
> 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?
No, it is pretty much the same thing, and it is equally bad.
> 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."
They'll say "Too bad, we told you we could have electrified it sooner
or later. You should have listened to us". It has already happened and
will happen again.
A couple of months ago there where an "interesting" thread on the
gcc-devel mailing list about signed int overflow behavior: some
application developers argued that optimizing assuming undefined
overflow behavior would break lots of applications. The answer they
got was pretty much: "then stop relying on undefined behavior!".
Sure, they might add an option to disable such an optimization for a
while if you ask nice enough, but:
- the option won't be there forever.
- would you use a library that forces you to a lesser optimization level?
> 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.
Type based alias analysis is here to stay. I wouldn't be surprised
that such code could already break on current compilers given the
> are doing egregious things with casting completely unrelated types back
> and forth all the time.
It is their application and the can do whatever they like, and they
will regret it when their application will break.
I do not think we want to consciously introduce these kind of bugs in
a boost library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk