Re: Re: A86: Problems compiling

[Prev][Next][Index][Thread]

Re: Re: A86: Problems compiling


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

> > and i had to totally rework the code even though i knew that how i was
> doing
> > the code was right but it was just a matter of the operations for some
> > reason not going through as planned...
>
> If it doesn't work, then you aren't doing the code right, no matter how
> correct you think it may be :)  This is of course there isn't a bug in the
> assembler or compiler, but with an assembler, there aren't that many
places
> for bugs to occur.  If you really think it's correct, look at it execute
in
> a debugger (like VTI's), which will often show you the cause of your
> mistake.
> > btw this happens with high and lowlevel languages, even in visual basic
> > sometimes it wouldnt get this right (if x=-1 then.. and i would have to
> > resort to if x+1=0)
>



> With high level languages, just because the code compiles does not mean
it's
> valid.  I have no idea what you are talking about in your example (looks
> like C, not VB), but you can make mistakes in C that can sometimes be
caught

c and vb have similar syntaxes, every high level language has the if-then
commands, and if you have an assembler that supports macros you can have the
if-thens too

> if you enable all your compiler warnings.  While the example that you gave
> is not ambiguous, it is similar to cases that are unclear and sometimes
> ambiguous, and thus should be avoided.  For example:

once again i did some debugging of my code by myself...ie i directly
loaded -1 into x right before the if x=-1 and it still didnt
trigger...software is made by ppl so in turn it is not always as perfect as
you think it is, even the z80 tables had a few bad commands that had to have
an update to correct those bugs in later versions


> 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

> if ((x = 1))
>   ...
>
> Granted, in the case of assigning a constant, a conditional is not needed,
> but combining assignments and conditionals is common in code such as
opening
> files, sockets, allocating memory, etc., to add error checking without
> cluttering the code too terribly.  You also have cases where code is
truely
> invalid, as there is no defined way for the compiler to implement it.
Each
> stement below is a separate example:

ummm like i said if you load a value in right before you try the evaluation
and you dont get the results you intended and it doesnt have to do with
other variables then you have to know that its not your code

>
> y = x + x++;   /* not valid to use a variable in the same expression that
yo
> u modify it in */
>
> foo(i++, i++);   /* function parameters can be evaluated in any order */
>
> I can't think of any more right now, but you should get the idea :)  Just
> because you think something's correct doesn't necessarily mean that it is.
> Don't be too quick to blame something else just because you think what you
> are doing is right.
>
>
>
>
References: