const, volatile, etc [was Re: #defines with parameters]

Guy Harris guy at auspex.UUCP
Thu Dec 22 19:39:23 AEST 1988


>The only one that takes tremendously seriously his own postings is you,
>Guy.

Rubbish.  Anybody who REFUSES to believe that optimizing repeated
references to variables, say, is anything other than a bug, and who
REFUSES to believe that aggressive optimization can be beneficial, and
REFUSES to give any evidence other than repeated postings of his own
pure opinions, is taking himself far more seriously than he deserves. 
That description fits you to a T, as *several* of the other posters on
this topic will agree.

>It is you that is getting in the popist mould, scorching the heretic with
>excommunications.  I may be advocating unfashionable ideas, but with
>reasonable arguments,

Excuse me, but who died and left you in charge, so that merely by
*stating* that your arguments are reasonable you can render them
reasonable?  Frankly, several people whose opinion I *highly* respect,
based on *demonstrated* technical competence, disagree with your
arguments and seem to disagree that they are reasonable.

>I am merely trying to persuade you that there are good points to be made on
>my side as well, not that I am infallible like a committee :->. All I get in
>return is cheap jabs at my person.

Right.  I'm sorry, but I can only conclude that somebody who REFUSES to
believe that those arguing with him can possibly be correct, and
REPEATEDLY claims that in some so-called "Classic" era of C it was
considered "unthinkable" to do the aforementioned types of optimization
and REFUSES to provide ANY objective evidence for this (and apparently
makes up reasons to dismiss evidence to the contrary) sure sounds like
he considers himself infallible.

>Oh yes. But the existence of people that claim, with fair and reasonable
>arguments, that aggressive optimization works so well on their hardware (and
>can be ported to other architectures as well), does not imply that it is a
>generally desirable idea.

*What*?  I very much doubt that the MIPS people don't think that
aggressive optimization is a generally-desirable idea.  In fact, I have
obtained the impression that they *did* think so - if they didn't, why
would they have bothered?

>C and UNIX were designed by and for the people that could not afford
>the MIPSes of their day, weren't they?

Define "MIPSes of their day".  MIPS boxes are hardly megabuck
mainframes.  They are actually quite cost-effective.

>Indeed, indeed. Please note that I have never said otherwise (I am even on
>record as having admitted that they do also introduce many interesting
>bugs).  While I think that register variable selection is one of the
>optimizations that are best left to the programmer, if he is competent
>enough, I have given some examples of optimizations that I think best not to
>leave to the programmer.  Please note that the sad argument about complex
>optimizer (un)reliability stands high in many people's everyday experience.

I hardly think there is a consensus for your view that aggressive
optimization of C is a Bad Thing.  Heck, a simple-minded assembler can
quite likely be more bug-free than most non-aggressively-optimizing C
compilers; shall we then discard C?

One can reasonably discuss the question of whether aggressive
optimization is a Good Thing.  One cannot do so, however, if one of
those involved in the discussion offers arguments that reduce to
"obviously, it's bad" rather than citing *objective* data to indicate
that it might be bad.  A lot of the hostility towards your postings is
really hostility towards your totally-unjustified unshakable faith in
your beliefs; when people *repeatedly* cite objective reasons *why* your
believes are *not* correct, you either ignore them or come up with even
more pronouncements (i.e., in response to people pointing out that
"Classic" C compilers did - *deliberately* - perform the optimizations
you decry, you simply dismiss that as being an indication that the
compilers in question are "buggy").



More information about the Comp.lang.c mailing list