[Coco] Re: optimizing

[KnudsenMJ at aol.com]

In a message dated 12/10/03 12:54:23 AM Eastern Standard Time, 
rtaylor at bayou.com writes:

> Speaking of this, I forgot to mention that I don't compound statements too 
>  much, but it's typical for me to turn this:
>  
>  stralloc(256)
>  mov(eax, MyString);
>  str.cpy("some text", MyString);
>  
>  into this:
>  
>  mov(stralloc(256), MyString);
>  str.cpy("some text", MyString);

I trust you don't do this until you've made more than a few test runs and 
never had the stralloc() fail.  In C, I always test for a NULL return from any 
form of alloc() fcn, and print an Alert message.  

But, after years of never seeing an Alert from that piece of code, I just 
*might* comment out the test of the return.  As the town councilor said "Nobody 
got killed on that curve for three years, so we took down the "Dangerous Curve 
Ahead" sign."

UltiMusE (all versions) is still full of tests that, like my seat belts, have 
never been "used."  But when your code is to be used by others, you can't be 
sure that *their* system might not trigger the error (like being out of RAM in 
an alloc() call).

Also, when some user tells you your program crashed on him, the more detailed 
error messages he can quote to you, the better your odds of finding the 
problem.

But I should probably go back and remove error checks whose real purpose was 
to check that I was using some exotic OS function correctly, like fork() in 
Linux.  I have not yet seen it fail to spin off a process, so I must be doing it 
right :-)

That is, checks on your own programming can probably be removed after a 
while, and left out in new code now that you know what you're doing.  --Mike K.