Out of String Space

 BBS: Inland Empire Archive
Date: 04-14-92 (09:34)             Number: 98
From: MATT HART                    Refer#: NONE
  To: JASON GORMLEY                 Recvd: NO  
Subj: Out of String Space            Conf: (2) Quik_Bas

Continued from previous...

    When using random access files, consider using a TYPE in far
    memory rather than FIELDing the buffer.  It's faster and
    much easier to change later on.  The TYPE definition itself still
    takes some Dgroup, but less than multiple strings and then FIELDing
    them.  Most string arrays can be fixed length.  You usually have
    plenty of far heap space, so just figure the longest string you'll
    need and make your fixed length string that size.  If you have a
    large amount of data, utilizing the far heap will allow you to
    create arrays of larger than 64K (compile your program with /AH).
    To really do this efficiently, the size of a single block of data
    must be a power of 2 (1, 2, 4, 8, 16, 32, 64, etc...).  This
    is the size of the TYPE stucture or the length of the string.

Finally, a few more notes on memory.  I always recommend that you
put '$DYNAMIC at the top of your programs, never use a non fixed
length string array unless it is absolutely positively neccessary,
DATA statements can ALWAYS be moved into a file - usually without
noticeable speed reductions, use COMMON SHARED rather than passing
lots of parameters, and use a named block common rather than a
global common when possible.  A couple of things on programming
techniques unrelated to memory - use integers!  They are usually
hundreds of times faster than the default single precision.  Put
DEFINT A-Z at the top of all your programs, right under the
'$DYNAMIC command.  Program with CALL's rather than GOSUB's.  This
makes splitting programs MUCH easier, and utilize named block commons
to share data between them (if you have lots of call's within a
block to the procedure, use a gosub there to save code memory).
Compile your programs with /D during the programming process.  This
will catch many errors that would otherwise be masked, and perhaps
even passed over for a while, making them difficult and time
consuming to find.  Good luck programming!

Matt Hart

---
 * Origin: Midnight Micro!  V.32/REL  (918)451-3306 (1:170/600)