13 May
2005
13 May
'05
2:16 p.m.
On Friday 13 May 2005 13:59, John Hogerhuis wrote:
On 5/13/05, Dave Dunfield <dave04a at
dunfield.com> wrote:
In K&R's "THE C PROGRAMMING LANGUAGE", 1978, section 2.12
"Precedence and
Order of Evaluation" is a discussion of compilers generating different
answers depending on interpretation (side effects). The first sentence in
the final paragraph reads: "The moral of this discussion is that writing code
which depends on order of evaluation is a bad programming practice in any
language."
I'll buy that.
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
Now I disagree with you - if you rely on a
particular implementations
handling of undefined behaviour, your abstraction is no longer clear
or unambiguous - in fact, quite the opposite...
The only correction to be made to your original statement, is that
the programming language must be used correctly - an idea that I
automatically assumed from the beginning, hence I originally had
nothing to add to it.
Well yeah, I'll buy that... there's usually no good reason to make
dependencies on implementation dependent behavior. I'd make exception
for areas where standards committees don't define something just
because they can't get squabbling vendors to agree... SQL standard
comes to mind... last version I looked at (a long time ago) couldn't
come to a standard 'date' type. Also some languages like Forth have a
culture of extending the language and room must be made for differing
implementations of even the same words.
All I was saying is that implementation dependent behavior is real as
opposed to abstract so you can determine exactly what any given line
of code will do as opposed to a dodgy/out-of-date specification or
design document.