> > No, a standard is useless information.
> >
> > What is useful to know is how a particular compiler ACTUALLY works.
>
> No that's wrong. Compilers can change without consideration for
> backward compatibility. Standards don't. That's the point of them. Even
> with visual C++ this is true.  You cannot rely on a compiler, but you
> can rely on a standard (mostly).

I disagree with you both.

While it would be ideal to rely on a standard, since all compilers should be
striving towards compliance, you just can't: compilers don't always
implement the standard to the letter, as we all know.

While it would be slightly useful to know how the compiler does it, you
can't rely on that either because one day it may change to suddenly comply,
or it may re-interpret the standard differently (but still allegedly
incorrectly), and get it wrong again. You also instantly lose portability by
relying on one compiler or architecture.

Either way, you will end up with code that breaks and needs updating.

There are some fundamentals that you just /have/ to rely on, such as
strcpy() copying a string from one place to another, or < (less than) doing
its job. You can't write code without these fundamentals.

But for grey areas, such as order of parameter evaluation as this all
stemmed from, DON'T RELY ON ANYTHING. Programmers write code. Compilers
optimise code. Stop trying to do the compiler's job by trying to save a few
poxy lines of code, and make it explicit, and impossible to be treated
ambiguously.

--
Jason Teagle
[EMAIL PROTECTED]




Reply via email to