All Databases MacTech Vol 09-1993

Mar 93 Tips, Tidbits

Volume Number: 9

Issue Number: 3

Column Tag: Tips & Tidbits

Tips & Tidbits

By Neil Ticktin, Editor-in-Chief

This column is your opportunity to spread the word about little bits of

information that you find out about. These tidbits can be programming related or they

can be user tips that are particularly useful to programmers.

MacTech Magazine will pay $25 for every tip used, and $50 for the Tip of the

Month. Or you can take your award in orders or subscriptions.

To submit a tip, send in a letter to the magazine. E-mail is our preferred

method, but feel free to send something via the US Mail. See page 2 for all addresses.

If you do send snail mail, enclose a printed copy and a disk copy of the letter so that it

does not have to be retyped.

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

Excerpt taken from DTS answer

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

Referenced by (2):