Tips & Tidbits

By Neil Ticktin, Editor-in-Chief

Tip of the Month

Writing code that will walk your array instead of using a standard loop to access the array elements will improve the speed of the code 40-400% depending on the compiler you use.

Standard array access:

FOR index := 1 TO kNumOfElements DO
    theArray[index] := someNumber;

Optimized access:
{--elementSize is the size of one array element. This is an example }
{  of an array of long integers, therefore SizeOf(LongInt)}
   elementSize := SizeOf(LongInt);
   elementPtr := LongIntPtr(arrayHandle^); {--Ptr to 1st array elmnt.}
   endArrayAddress := ORD4(elementPtr) + elementSize * kNumOfElements;
   WHILE ORD(elementPtr) < endArrayAddress DO
   BEGIN
   elementPtr^ := someNumber;  {--elementPtr^ accesses the array }
  {elements.  Increment the elementPtr }
  {to point to the next elt in the array.}
   elementPtr := LongIntPtr(ORD(elementPtr) + elementSize);
   END;

Essentially, you're forcing the compiler to generate more efficient code for your loop.

-- Marek Hajek, Reno, Nevada

Self Documenting Code

Do yourself a favor: write self-documented code. Have you ever looked over source code that makes no sense whatsoever? Worse yet, have you ever looked at your own code six months later and you can't make heads or tails of it?

Try self-documented code. This is where you name functions and variables so well that there is no mistake about what they do.

Consider a function you are writing that, say, strips off all the trailing space characters from a string. The WRONG names to give this function are "String1," "StrStrip," "FixString," to name a few. A far better name would be:

  remove_trailing_spaces_from_string

Yes, the name is long, but it pays off in a big way! If you came back a year later and looked at the code, well, what does this function do? Duh! Does it remove trailing spaces from a string, perhaps?!

The same rule applies to variable declarations. Instead of the ol' fashion "i," "k," etc., start naming your variables real English names that make sense. Example:

length_of_text instead if "i" or "len"

number_of_records instead of "r"

users_name instead of "UserStr" or "str"

You will find this system is worth far more than pages of (meaningless?) comments!

- Gar, DataPak Software

DrawPicture Bug

There is a crashing bug in DrawPicture that can happen when you draw pictures that contain very wide PixMaps. DTS has verified that this is a bug in QuickDraw (on machines with IIci ROMs or later running 7.0 or later. Currently, that means the IIci, IIfx, LC, IIsi, Classic II, PowerBook 140 and 170, and the Quadras all have this bug). Thanks to Forrest Tanaka for the following information.

The problem happens with pictures that contain direct PixMaps that have been compressed using run-length encoding. The bug is that DrawPicture allocates two times the rowBytes value of the direct PixMap on the stack without first checking to make sure that there’s enough space to grow the stack that big. For wide PixMaps, two times the rowBytes can be very big, and so the stack can easily overflow when you try to draw a picture that contains a wide PixMap.

A reasonable work-around for this bug is to increase the size of the area of memory that’s reserved for your stack, which is just above your application’s heap. By default, Color QuickDraw machines provide you with a 24K stack. The widest possible PixMap has 16K per row, so multiply that by two and you get 32K as a maximum amount of stack space DrawPicture needs to draw the direct PixMap. Add to this a lot of slop for all the other stuff that you’ll have on the stack when you call DrawPicture, and a 48K to 64K stack becomes reasonable, in my opinion at least.

Increasing the size of the area of memory for the stack is done by setting the address of the top of your heap farther down from where it is by default. The SetApplLimit routine lets you set this address, and the GetApplLimit routine gives you the current address of the top of your heap. To add space to the memory that’s set aside for your stack, you can use something like the following line of code:

SetApplLimit(Ptr(Ord4(GetApplLimit) - kAdditionalStackRequirements));

kAdditionalStackRequirements is the number of bytes of stack space you’d like above and over the default stack size. Make sure you call this before calling any other routine - before MaxApplZone, MoreMasters, and InitGraf.

If you want to find the existing size of area of memory for the stack, you can get the address of the bottom of the stack (the part that’s highest in memory) from the low-memory global called CurStackBase which is located at $0908. Subtract from this the return value of GetApplLimit, and you get the current size of the area of memory for your stack.

- Mike Scanlin, Mountain View, CA

The Easy way to store disks

I have looked far and wide for a way to store hundreds of diskettes. Most of the vendors want big dollars for custom disk holders. They look great in plastic or metal. Holding hundreds of disks though can get very expensive.

I have found that a three-drawer kit can be assembled easily. These kits are found in the hardware section of your local retailer. They are in the place where the furniture is sold for garages and children's rooms.

These drawers are made out of particle board and masonite. Each drawer is 4 1/2" high by 15" deep by 13" wide. I can put in 3 rows or 100 disks per row in these with plenty of room to thumb through the diskettes. That is 300 diskettes per drawer.

They can be assembled even by me or my kids in about 20 minutes. And instead of paying $100's to hold the disks, I have less than $25 into holding 900+ diskettes.

The disk holders are 15" High x 15" wide x 15" deep. They are manufactured by SturdiCraft, 2742 Homdale Rd., Klamath Falls, OR 97603 phone (503) 882-4406. They are available through Fred Meyer, Sears catalog sales, HomeBase and many local hardware stores. Or they are available direct from SturdiCraft for $34.30 including shipping and handling. Ask for Model S-350. Some assembly required.

- Bruce Kyle, Beaverton, Oregon