Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?]

[Joe Keane <jgk@jgk.org>]

In article <4vroh3$17f@goanna.cs.rmit.edu.au>
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> writes:
>I would go so far as to say that
>
>	int count_blanks(char const * const s) {
>	    int i, r;
>
>	    r = 0;
>	    for (i = 0; i < strlen(s); i++)
>		if (s[i] == ' ')
>		    r++;
>	    return r;
>	}
>
>is a _good_ function.

That's just bad code.  It specifies a *quadratic* algorithm for a very
simple operation.  My impression would be that the coder doesn't
understand some basic things about C programming, or they're just
inconsiderate.  How hard is it to put the length in a variable?

It's a basic fact that, in the idiomatic `for' loop, the test is
evaluated every time through the loop.  If the upper bound is fixed,
it's really good practice to put it in a local variable.  This makes it
perfectly clear to the compiler *and the reader* that it won't change.

Conversely, calling a function on every iteration connotes that the
value may change.  In a less simple example, there may be a genuine
question about what in the loop causes the bound to change.

>The ONLY strlen() optimisation that is needed here
>is one that is completely general:  strlen() is a pure function and its
>argument does not change, so the strlen(s) computation can be hoisted out
>of the loop.

It's not a pure function.  Whether the argument changes isn't the point;
it's a local variable and it's clear to everyone that it's not changed.

In article <01bb9360$21d0dbe0$87ee6fce@timpent.airshields.com>
"Tim Behrendsen" <tim@airshields.com> writes:
>Yes, yes, I've heard this before.  The compiler knows all, sees all,
>fixes all.  If my strings are a few thousand bytes long, you
>don't think it may be *slightly* inefficient?

>I can easily call clear correct code stupid if it is blatently
>inefficient.  I don't expect the compiler to fix bad code, and
>thus I am never disappointed.

Really.  I expect an optimizing compiler to do a decent job of low-level
things, such as allocating registers, selecting instructions, scheduling
instructions, and so on.  If optimization is turned off, the code will
get slower, maybe two to five times, but a constant factor.

I don't expect the compiler to work miracles, to turn crap into gold.
That would include changing a quadratic algorithm to a linear one.  Some
people may think that it's nifty, but i think it's just a bit disturbing
and i'd rather have compiler writers concentrate on compiling good code.

In article <slrn523tpg.ce.mdw@excessus.demon.co.uk>
Mark Wooding <mdw@excessus.demon.co.uk> writes:
>Erk!  No it isn't.  A pure function is one whose value depends only on
>its arguments.  sin() is pure.  strlen() isn't.

In article <50650h$rek@goanna.cs.rmit.edu.au>
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> writes:
>This is where I was using sloppy language.
>The way I was using language, the argument *is* the "null-terminated
>byte string" (to use C++ draft standard terminology), and the pointer
>is merely the mechanism used to refer to it.

You can't blow off a level of indirection so easily.  If we're talking
about some expression that just involves the value of the pointer, we'd
agree that it's just CSE and there's nothing controversial about it.

>In the program fragment under discussion, it was not merely the pointer
>that was constant, but the NTBS itself.

I think that you misunderstand the `const' keyword.

>If I do
>	n = strlen(s);
>	/* much code that does not change s */
>	/* NOT the NTBS that s refers to */
>	m = strlen(s);
>it is necessarily the case that m and n will be the same size_t value.

I'm unclear on that comment, but if there are pointer stores in there,
the length may be changed, even if `s' isn't changed.

>The answer is unequivocally "Yes it CAN."

In your example, it is possible.  But it's based on a lot of assumptions
and it's not something you should depend on.  In many similar examples,
the compiler *must not* remove the duplicated calls.

--
Joe Keane, amateur mathematician