[futurebasic] RE: [FB] "AS LONG" vs &

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : April 2001 : Group Archive : Group : All Groups

From: "Edwards, Waverly" <wedwards@...>
Date: Sun, 15 Apr 2001 20:26:07 -0400
Alain, you are correct in stating that I should use the correct type
identifier.  I may be the only one that thinks this way but I'll say it
anyway.  When variable suffixes could be eliminated for type identifiers I
was under the belief that the "&" and LONG were identical.  Until I ran into
the problem with  the GWorlds, everthing worked exactly as I thought.  After
crashing a whole lot for no apparent reason I tried what seemed like a silly
idea to change to a suffix.  It appeared to work most of the time.

I sent Staz a note to the same effect, asking for a technote.  I thought
that others might be under the same misconception.


-----Original Message-----
From: Alain Pastor [mailto:apastor@...]
Sent: Wednesday, April 11, 2001 4:44 PM
To: futurebasic@...
Subject: Re: [FB] "AS LONG" vs &

Chris Stasny wrote:

> >%
> >
> >Hi Waverly,
> >
> >  > When I switched from defining the variable theGWorld AS LONG
> >  > to theGWorld& 99% of my crashes went away.
> >
> >Wow, I've touted the &-pill as analgesic relief for
> >pain-in-the-brain.  But you seem to have applied & in the
> >realm of voodoo, the occult, and buggggzzs.
> >
> >Magical!
> >
> >LS
> Items with an ampersand (&) are taken as pointers. Items without
> ampersand are taken as records. If you want to slap an offset on the
> end of a generic long integer variable, you will have to use a
> variable with an ampersand.
> EXAMPLE (Old style pointer)
> DIM TEhndl&
> top = TEhndl&..teViewRect.Top%  : REM this works
> Or  (new style record) ...
> DIM TEHndl as ^^TErec
> top = TEhndl..viewRect.top      : REM this works
> top = TEhndl..viewRect.top%     : REM compiler gets confused here
> In the last case FB has to start guessing. Is TEHndl the record or
> does it point to the record?
> This is an imperfect example off the top of my head, but the moral of
> the story is this: If you are going to use offsets other that those
> in true records, you should stick with an ampersand.

Your example is almost good except that for the demonstration you should
used an example with a pointer instead of a handle I guess. Because the
following lines :


top = TEhndl..viewRect.top%     : REM compiler gets confused here

won't compile at all with an undefined constant error.

However, Edwards' statement is somewhat misleading. One can think that he is
saying there is an obscure bug in the DIM AS LONG clause that can be cured
using the & symbol. It seems that his problem was due to the use of an
incorrect variable type, using a long instead of a pointer, therefore his
statement might have been as well : "When I switched from defining the
variable theGWorld AS LONG to theGWorld AS PTR 99% of my crashes went away."
Another moral for the same story could be: If you are going to get rid of
type identifiers in your code be prepared to use the correct type for your
variables as well as the correct field names for your records.
I bet this is a good candidate for a technote.