Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tnc!m0154
From: m0154@tnc.UUCP (GUY GARNETT)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Good Programming stops guru |||| and BNF of C++
Message-ID: <658@tnc.UUCP>
Date: 9 Jan 91 14:25:50 GMT
References: <1806@winnie.fit.edu>
Reply-To: m0154@tnc.UUCP (GUY GARNETT)
Organization: The Next Challenge, Fairfax, Va.
Lines: 54

In article <1806@winnie.fit.edu> rcs91900@zach.fit.edu ( Charles Stockman /ADVISOR-Clutterham) writes:
>First of all I wanted to thank everyone who answered my question about how 
>I could descrease the number of times the guru appeared.  However, I would
>like to continue this discussion, so could someone tell me how to do safe
>coding (coding that protects you from the guru).
>
>ex : One technique that I know is to make sure that all files and 
>     resourses that were allocated to a program are released by the
>     programmer.
>
>My next problem is that I am looking for the BNF of C++ .  Could someone please
>mail it to me 
>
>Once again --> Thanks a lot for your help


Sorry, I don't have the BNF for C++ ... but I do have some basic tips
for defensive programming.  I realize that most of the readers already
know most of these, but repetition never hurts.

* Check all return values - Most library functions return a special
value for error conditions.  Test for them.  I realize that this is
basic stuff, but at some point that AllocMem of 32 bytes that "can't
fail" will fail, and then its off to see the GURU.  This also includes
testing file opens & locks, and so on.  If it returns a value, check
it before you go on.

* Pay attention to pointer usage - there have been commercially
released programs which reference a null pointer, and thereby trash
AbsExecBase.  All it takes is one, buried somewhere in your code
(cleanup and terminate routines are especially prone to this).  One of
the indicators of this problem is that the machine Guru's *after* you
have exited your program (ie: when you try to do something else).

* Quick way to test for outstanding files or memory allocation - run
your program several times in succession.  Use Avail and note the
amount of free memory after each one.  The first time you run your
program, any needed libraries will be loaded into RAM.  After that,
you should get the same amount of free ram each time.  Beware if the
amount goes down by the same amount each time!

* There are several good PD system and memory monitors around.  If
they suit your needs, use them ... Almost all of them will let you
spot outstanding file allocations, and others are useful for detecting
the null pointer problem.
 
* Plan your program (even if you "don't do designs") - Planned in
advance, your program can have efficient ways of performing its
internal tests, and can recover or exit gracefully.  Some of the best
have an "exit module" which closes files, deallocates memory, and
closes libraries for the whole program on exit.  Grafting this kind of
stuff onto an existing program is harder.

Wildstar