Amiga ISO Collection/AmigaUtilCD2.iso/Programming/Basic/MAXONB32.DMS/in.adf/docs.lha/B-Hints&Tips

Text File | 1994-10-31 | 5.9 KB | 181 lines

Hints and Tips



This chapter shows how you can get the most out
of programs written with the MaxonBASIC
compiler. It is not necessarily intended only
for the advanced programmer.


Using MaxonBASIC

Making a more efficient program requires
knowledge of the features of MaxonBASIC. The
following suggestions are intended to give you
a firmer understanding of what can be done; we
also hope that you will use this information as
the basis for a more detailed exploration of
MaxonBASIC.


defint a-z

It is a good idea to have this line in your
program, it makes the default variable type a
short integer. The main benefit from using ints
is speed. The source becomes more
understandable when &, !, and # are used
explicitly.


rem $VARCHECKS

This forces variable checks on. The primary
benefit of this is that you can avoid
unnecessary bugs caused by undefined variables
in sub-programs and functions. This is
especially important when programming using the
operating system include files.


STATIC variables in SUBs and FNs

STATIC variables retain their values when a SUB
or FUNCTION is exited and re-entered. There is
a speed benefit in using STATICs as opposed to
LOCALs: STATICs are only allocated once,
whereas LOCALs must be allocated every time a
SUB or FUNCTION is invoked. If your SUB or
FUNCTION is recursive then LOCAL variables must
be used.


INCR and DECR

These two statements respectively increment and
decrement the value of a variable by one. When
used on array elements they are considerably
faster than e.g. Arr(1)=Arr(1)+1.


==

The double-equals comparison operator has a
different meaning depending on the type of
value compared. When comparing strings, a case-
independent comparison is made. It is
considerably faster than using UCASE$ or LCASE$
and then comparing, or doing something like IF
fred$="A" or fred$="a" THENÉ When comparing
numeric values, == is used as ´almost equals´;
rounding errors can thus be avoided. There is a
performance degradation when using == on
numeric values. Note that this is a MAXON
extension.


! as opposed to #

When using floating point maths, it is a good
idea to know exactly how much accuracy is
actually necessary. Single-precision is much
faster than double-precision, due to the degree
of accuracy required. If you want floating
point, but do not need such a high degree of
precision, single-precision is the variable
type to use. The exception to this is if you
have a maths co-processor fitted to your system
where doubles may actually be faster than
singles. The reason for this is that our double
routines use the system libraries that will
automatically use an FPU if installed whereas
the single routines are software only.


Use pre-tokenised files

If you are using our operating system include
(.bh and .bc) files then it is well worth
building a pre-tokenised file containing those
include files that you are using - you will get
much faster compilations as a result.


VARPTR, SADD and PEEKtype

When using VARPTR and SADD, you must be very
careful. The reason for this is quite simple:
owing to the dynamic heap allocation and the
blindingly-fast garbage collection of
MaxonBASIC, strings are prone to move around
without any prior notice. This is normally
completely transparent to the user, but when
using these functions it becomes a factor to be
reckoned with. If you are going to use them,
call the functions just before accessing the
variable or array. In addition the address of
any array will be invalid if a REDIM or ERASE
statement has been executed since VARPTR was
used to find the address.
After using these functions, a PEEK or POKE is
usually inflicted upon the data at the returned
address. MaxonBASIC has faster varieties of
PEEK and POKE and they are type-specific. The
can be used to great effect e.g. when parsing a
string.
Let us suppose an entire file has been loaded
into a single string using INPUT$; this is
quite possible because strings in MaxonBASIC
are only limited by available memory. SADD is
called to determine where the string is. To go
through the file at high speed, all you need is
to remember your place in the string and PEEKB
from the location that you need. Do not use
PEEKW or PEEKL because strings can be on odd
boundaries and an address exception will occur
if you try to read a word or long from an odd
address.


Making Your Programs "No-Limits"

If you have been used to programming in more
primitive versions of BASIC or in Pascal or C,
avoiding arbitrary restrictions on the size and
type of data that your program can manipulate
can be hard work. For example, having a limit
on the length of names that you can type into a
business application can sometimes be very
annoying. Similarly avoiding limits on the
lengths of files and in line lengths can save
you a lot of time, if say the file in question
has odd end-of-line markers that mean that your
program treats the whole file as one line.
The following hints should help to avoid this
sort of problem:
When reading in or adding to arrays, have code
to make the array larger if need be. In general
adding a few elements at a time is not a good
idea because the program may start spending all
its time moving arrays. Normally it is a good
idea to start off an array with the size as
just larger than a typical requirement, but if
an array is only used occasionally then the
dimension can start off small. For example, if
writing a cross-reference program for
MaxonBASIC programs, it would probably a good
idea to start by assuming that the number of
line numbers is small (say 10) and then if the
program turns out to be a horrible old-
fashioned program with a line number on every
line then the arrays used for holding them can
be grown using REDIM PRESERVE at, say, 100
elements at a time.
When using byte or record numbers in files or
strings use long integer variables (terminated
with &). This should remove automatically many
32k or 64k limits on programs that are designed
with 16-bit integers in mind.