The only problem apparent in this situation is that gcc has crashed.
Had the compiler not crashed, the compiler would have gone to produce
either a correct or a faulty binary. Since the vast majority of the
time, gcc produces the former, it is much more likely that this crash
is preventing gcc from producing a correct build than it is somehow
avoiding an incorrect build.
I don't buy that at all. Presumably the authors of g++ put those
assertions in to check for things that should not happen and that
therefore signify a bug when they do happen. I don't think anybody
writes asserts that fire when everything is going to plan do they? And
if you've hit a bug, all bets are off. The program state is something
other than its creator intended and therefore the behaviour of
subsequent code can not be predicted (without having the code
available to read). You're correct to say that the output could be a
correct binary, but incorrect in your assessment of the probability of
that happening. The likelihood of g++ producing a correct binary when
it does not encounter a bug in the process (very high) is irrelevant
to the likelihood of it producing a correct binary when it does
encounter a bug. To say the least, it would be courageous to rely on
the compiler's output.
In other words, you can spend time debugging your C++ compiler instead
of your own C++ programs.
No, you spend your time *reporting* a bug in your C++ compiler. Or you
can choose not to bother. Many software providers offer you a means to
report problems if you choose to. In the specific case of an open-
source project, you *can* also choose to debug it yourself if you want
to. But that's entirely up to you and entirely separate from choosing
whether to report the bug or not.
I think that a better compiler would have the asserts turned off. The
point here is that a more thoroughly-tested compiler would see no
benefit from shipping with its asserts enabled.
A *perfectly* tested compiler would see no benefit, but I don't think
such a thing exists or reasonably could exist.
Shipping a program
with asserts enabled can only mean that the software has not been
adequately tested.
Are you saying that you think there is a practicable amount of pre-
release testing that can guarantee a product like g++ will be 100% bug
free?
So in this case, anyone who uses g++ is
effectively participates in the product's QA.
And what do you think happens when any other piece of complex software
is deployed to a market that is orders of magnitude larger than the
pre-release testing team?
And while such an arrangement may be reasonable for a free product
like g++, it probably won't fly for those who program with a $500 C++
compiler. Customers who pay money for software do so with the
expectation that the software will be tested before it is shipped and
that it will run reliably after it has shipped.
As, I'm sure, do customers of purported stable releases of free
software. Nobody is suggesting g++ falls over every time it tries to
compile something, just that on the rare occasions it does fall over,
it's good that it does so in a way that lets you know you can't rely
on anything it just produced, and gives you the option to provide
useful feedback to the people who can fix it.
Leaving asserts
enabled in a shipping program has the completely opposite effect - the
asserts make the shipping program less reliable (that is, it is more
prone to fail),
Again, only if one writes an assert that can fire when nothing is
wrong. I don't think people do that.
Two assumptions:
1. Asserts will only fire if there is a bug in the program.
2. It is not possible to guarantee the program is 100% bug-free before
release.
If you agree with those two assumptions, the choice is between leaving
asserts in so something obvious and controlled happens if a bug is
encountered or taking asserts out and having something unpredictable
and (worse) possibly not immediately noticeable if a bug is
encountered. I don't see how the latter could be preferable. There's
no concept of being more likely to fail with asserts enabled. All that
is more likely is that the user knows about it. That's good.
If you don't agree with the assumptions above, please do explain why.
and all but eliminates the chances that the developers
will have tested the software before it shipped - and not just rely
on those who use the software to make up the difference.
If that sort of attitude is prevalent, the people managing the
development process are going to need a far more fundamental strategy
if they want to produce a well engineered product.
Gavin Deane