Re: Re: A86: Problems compiling

To: assembly-86@lists.ticalc.org
Subject: Re: Re: A86: Problems compiling
From: rabidcow@juno.com
Date: Tue, 12 Dec 2000 23:45:20 -0800
Reply-To: assembly-86@lists.ticalc.org



On Wed, 13 Dec 2000 00:24:52 -0600 "Steve"
<comfortably_numb_@hotmail.com> writes:
> 
> there wasnt any room for a mistake to occur...i even had simple 
> things to
> see if the ball was on the screen and for some reason they wouldnt 
> work and
> i do my own debugging with error trapping in the code :P

If you could try to find the simplest case when this happens and it turns
out there _is_ a bug in the assemler, that might help get it fixed.


> > if (x = 1)
> >   ...
> >
> > In this example, the rvalue 1 is assigned to the lvalue x, which 
> is then
> > used as a truth value for the conditional.  This is valid C, but 
> it can be
> > unclear as to whether or not an assignment was truly intended.
> Parenthesis
> > around the assignment clarify both to the compiler and to a human 
> reader
> > that an assignment intended:
> 
> visual basic knows that u want an expression evaluated and doesnt 
> need more
> parens and actually takes them off if you add them on

basic *assumes* you never want to do an assignment in the conditional
secion of an if-then statement.  That way you don't have to think about a
separate operator.

c is more flexible, the correct operator in c to test for equality is ==
and usually when people use "if (x=1)" it's a mistake (and often the
compiler will issue a warning)

-josh
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.