JasonB (no@spam.com) on 8/25/09 wrote:
---------------------------

>of compilers, yes. What is your point?

My point is that "standard" and "conformant" are rather
unhelpful concepts. There's stuff that's officially
"standard" that shouldn't be used because hardly anyone
implements it. There's stuff that's arguably "conformant"
but completely useless.

So it comes down to culture: you work in one kind of
culture - small group of competent developers, Windows,
MSVC++, adherence to coding standards. I work in a very
different culture - largish group of developers of (to
be polite) varying competence, Linux, g++, no ability
to enforce coding standards. Applying the judgments of
one culture to practices in another culture is not a
very productive exercise, any more than criticizing a
Kalahari Bushman for not wearing a jacket and tie.

>Should I have said "there is no practical substitute"?

It's ugly, but it's practical: we do it, where we have to,
it works, and we can sell the app.

>I just searched through our code and we never use dynamic_cast for any of
>our own code -- properly designed application-level OO code has very few uses for

Oh, I agree. If you're using it, it's probably poor
design. But that was my original point: are there
features in the language standard that you never, or
hardly ever, use ? We can put dynamic_cast on that list.

>With exceptions you can freely choose at any level to handle any subset of any
>possible exceptions without ever having to worry about anything falling through
>the cracks, and without having intimate knowledge of the implementation of the code

The problem is not with the places where you handle
or don't handle exceptions. The problem is with code A
that worked just fine without exceptions, but becomes
broken because code B starts throwing an exception and
code C catches it and tries to recover.

Like this:

void A(char* fname)
{
int fd = open(fname, O_RDONLY, 0);
if (fd < 0) ... error check
ParseTree* foo = ParseFile(fd);
close(fd);
}

Is that code ok ? Yes if ParseFile() can't throw an
exception; no if ParseFile() can throw an exception -
in that case we'll leak the file descriptor fd.

And I can't tell by looking at this code alone. And
if ParseFile changes, nothing in the compiler is even
going to warn me that the non-local effects of the
change make it necessary to review and possibly change
this code.

Yeuch!

>The second is functionality: throwing an exception guarantees the destruction of
>all objects on the stack from the thrower to the catcher, allowing RAII to be used
>to guarantee no resources leak and the program to be exception safe (to the point

Except it doesn't. It guarantees that all *objects* get
destroyed. But there are resources that aren't necessarily
objects with destructors. So this becomes a bit half-assed.
Sure, if all your code everywhere carefully follows the
necessary rules, then exceptions can work out pretty
well. But a) verifying global compliance to rules that
can't be automatically checked is a hard problem,
and b) enforcing *new* global rules in an old codebase
is just about impossible.

>I really don't care what mediocre developers will do. Mediocre developers will
>always find ways to do things wrong.

Like I said, different culture. In my environment, the
best choices are to make sure that anything subtle is
carefully encapsulated (preferably in a single file);
and to apply defensive programming at the interfaces
(assertion checking etc) so that when someone does
something stupid, you can detect it and tell them about
it quickly.

>This not only simplifies code (no nested if statements to handle resource acquisition
>and release -- e.g. you can safely return or throw if you fail to open the file
>in the second case without having to worry about the memory being freed) but it

Sure, that's nice. But making sure that all your code
follows that style is back to the "verifying compliance to
global rules not automatically checked" problem. Your
culture makes that feasible, and that's good for you.
Mine doesn't, and that leads to different design choices.