On Thu, Mar 18, 2010 at 01:30:13PM -0400, Martin Cracauer wrote:
> > garbage collection (which only helps with memory resouces), or
> > reference counted smart pointers.
> Resources are more than memory.  In the age of 64 bit virtual memory
> memory leaks are actually a comparably minor issue.
> File descriptors not closed, files not synced, TCP connections left
> hanging, messing up the list of forked children that you expect to
> return are much more severe issues.  There resources are subject to
> the same limits as ever.
> Fighting those issues in long-uptime programs is much easier with
> exceptions than without.  Forbidding them makes no sense, except
> specifically if you think your programmers are too dumb.

Alright, instead of trusting to memory or speculating, I looked up
a reference, the coding standards for the UK joint strike fighter
which I've read Bjarne Stroustrup refer to positively.  I dunno if
this is a good example for safety critical code, though.  Well, if
you mean the safety of the pilot and not the poor chumps having
missiles lofted at them, I guess it works. So under fault handling
it does indeed ban C++ exceptions, but the justification is

"AV Rule 208
C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
Rationale: Tool support is not adequate at this time."


So anyone have a guess at which tools they mean?  The compiler itself
or testing and verification tools?

> > at top level or some global singleton that never releases a reference
> > to some huge tree of objects.  Too often it seems enough to say
> > only, "there are resource leaks."  I guess you folks are probably
> > reading better code than I am.  Still, tell me you haven't talked
> > to people who think it's perfectly normal acceptable practice to
> > run servers with a wrapper of some kind that kills them and restarts
> > them periodically.
> Then you are not talking about a long-uptime program.

Well, the intention generally is that servers be long uptime I'm sure,
but there aren't enough non-dumb programmers apparently.  Truly,
you've never encountered a system administrator who follows this
practice without complaint (or at least without surprise)?

> The rule should be to only let programmers who know what they are
> doing write safety critical code.

I hope only the best write this kind of code, but if the #1 rule
was that where we need perfect systems we will get them by using
perfect people, well, I think I'd do a lot of walking to get around,
preferably on country paths far from any machinery with computers
in it.  It does seem that some embedded programmers use this practice
of avoiding parts of their languages.  Perhaps they have some

Mike Small

Boston-pm mailing list

Reply via email to