Re: Re: A86: Problems compiling
[Prev][Next][Index][Thread]
Re: Re: A86: Problems compiling
> 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
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:
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:
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:
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.
Follow-Ups:
References: