ambiguous ?

[T. William Wells]

Followups have been directed to alt.flame.

In article <14092 at lanl.gov> jlg at lanl.gov (Jim Giles) writes:
: >>... C has _many_
: >>more contexts which are _both_ undefined and without efficient ways
: >>of overriding the ambiguity.
: >
: > Sure there are efficient ways:  avoid depending on the ambiguity.
:
: I _don't_ depend on ambiguity.  I _don't_ use language features which
: admit of ambiguous behaviour.  Unfortunately, there is no way of using
: C efficiently without also using ambiguous features.

I've been programming mostly in C for seven years now, after
programming in more than a dozen other languages, including
assembly, for another eight, writing software that had to be as
near as absolutely portable as possible (it ran on well over a
hundred different systems), with customers that *did* bitch every
time I screwed up.

Efficiency was a great concern, because end users, you know, the
ones that are the ultimate justification for this business, had
to wait for my programs to finish. And a slow product meant no
sales. I'm known for usually arguing the efficiency side of
programming because I *hate* fat programs. Because of that, I've
developed an arsenal of techniques for writing efficient code;
when I work on improving other people's code I tend to, without
doing nonportable things, improve the code speed by at least 25%.

When it comes to writing portable and efficient code, I generally
know what I am doing.

You, Mr. Giles, just don't know what you are talking about. You
have it on the brain that unspecified behavior causes problems.
And you are magnifying the problem all out of proportion. You are
also ignoring, either out of incompetence or because you just
don't want to hear it, methods of avoiding the problems.

:                                                       (For example, in
: the current discussion, the only way to get a reliable evaluation order
: for the function arguments is to do redundant assignments in previous
: statements.  Most C compilers are _VERY_ bad a optimizing such sequences.)

This is a perfect example of your fixation. First: good
programming practice says that one should avoid multiple side
effects in a statement. There are obvious exceptions, don't waste
my time telling me about them.

Second, your attention to efficiency in that context is
misplaced. Consider the code generated: one function call with
two arguments and their associated computations, as compared with
the same plus one extra store instruction. And, of course, if you
care THAT much about efficiency, you are a damn fool for trying
to get it in a higher level language anyway. TANSTAAFL, folks.

But if you *must* do that, and you don't like the cost of the
redundant assignments, you use the COMMA operator.

You see, if you knew beans about C optimizers, you'd know that
all but the worst don't do too badly with *intra-statement*
optimization. So, if "a=b++; foo(a,b);" bugs you, turn it into
"a=b++, foo(a,b);" and you will likely get better code than you
would have otherwise. (Not, mind you, that I'd ever; there are
plenty of very good reasons for not, and plenty of other, good,
ways to squeeze efficiency out of C programs.)

There are workarounds for each kind of undefined behavior, AND
NONE OF THEM ARE ESPECIALLY EXPENSIVE, your claims to the
contrary.

: > enough, this seldom bothers experienced C programmers.  Nobody ever claimed
: > C was suitable for beginners.
:
: I am a reasonably experienced C programmer.

No, Mr. Giles, you are a person who has programmed in C for years.
You may have knowledge, but you are lacking in C wisdom.

:                                                        Yet I am _always_
: bothered by the ambiguous features of the language.

Solely because you have not bothered to learn efficient ways to
avoid them. You've wasted your time bitching about them.

: bothered by the ambiguous features of the language.  I am bothered that
: there is no efficient way around them.  You can't even force the evaluation
: order of an expression in C.

Use the comma operator. If it really matters. Which it rarely
does.

: > Rational arguments are useless against superstition.
:
: Presisely so.  That is why it's so hard to convince C fanatics that
: there may be something wrong with their god (the C programming language
: that is).

I'm no damn C fanatic. But you are an anti-C fanatic. The mark?
That you complain about something that *makes no difference* in
the real world.

: The primary purpose of a programming language is to _unambiguously_
: specify the operation of an algorithm.

Bull. The primary purpose of programming languages is to get the
job done. Which leads to a secondary purpose: unambiguous
specification of the algorithm. But that is not, past a certain
level of functionality, an imposition on the *language*, it is an
imposition on the *programmer*.

It is clear that you don't care to exercise the responsibility to
be a good programmer. You just want to complain about something
you don't like.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill at twwells.com