HS>Maybe some people don't rely on compilers to compile the fastest code
HS>possible.
CB>ROFL!  In a few years, when you've learned a bit more about programming,
CB>differences in the code different compilers generate, how different
CB>switches and optimizations can radically change the generated code,
CB>programming for different platforms or even similar platforms but
CB>different CPUs, etc., you'll realize just how incredibly funny that
CB>statement is!! 
Funny? I don't see how improving ones code can considered funny.
If your tender chimp brain actually bothered to read the thread maybe you'd 
understand what that meant.
CB>There is only so much you can do algorithmically in a HLL.  There comes
CB>a point where it is very much up to the compiler as to how well / fast
CB>the resulting executable runs.
Thank you for informing me, now I know that a compiler generates optimized 
code. Where would I be without your free informative lessons carey.
CB>For example, switching from a bubble sort to a quick sort might decrease
CB>your run time from O(N^2) to O(N log N), but then after that, it's up to
CB>the compiler whether it generates code that needs 10 seconds for 'x'
CB>items, or 20 seconds for the same 'x' items.
My comment merely said "Maybe some people don't rely on compilers compiling 
that fastest code possible".
Lets see now, where did I say that a compiler doesn't optimize?
Does a compiler change a *256 to a <<8?
Obviously not, so why not optimize it yourself?
But according to you thats wrong so don't do it.
CB>Does the compiler generate inline ABS() and memcpy() functions or are
CB>they so dumb they require calling a library routine.  When it transfers
CB>memory, does it do it a byte at a time, or is it smart enough to take
CB>advantage of things like 32 bit registers which can move 4 bytes at a
CB>time.  Does the compiler automatically align things on word boundaries,
CB>or does it generate code where a variable can be misaligned and require
CB>more memory accesses?  Does the compiler allow generating better 486
CB>level code, which is tuned to the way a 486 CPU operates, or does it
CB>generate code for cruddy, slow 386s?
Read the thread idiot
CB>For many things, such as the few I mentioned above, you _have_to_depend_
CB>on the compiler, because there is a good chance they are outside of your
CB>control, and even if not, they might be dependant upon the user setting
CB>or not setting some particular switch that may not be the default or
CB>that may interact with some other switch.
Ofcourse, everyone depends on the compiler to compile code. But sometimes you 
have to make an optimizations by hand because the compiler can't do it.
Obviously, it's no wonder I see so much sloppy code, if you actually took 
notice that not everyone has the latest machines to date you might consider 
trying to make the fastest code possible, not relying on the compiler to do 
it.
... For a bug-free environment do NOT run this program!
--- Ezycom V1.48g0 01fd016b
---------------