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

[SYS0.MICRO-NEIL.COM@ (madscientist)]

In <4vroh3$17f@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>"Tim Behrendsen" <tim@airshields.com> writes:

.snip..

>standardisers say "that's a quality of implementation issue which is
>outside our scope".
>
>For an *exact* parallel, consider function inlining.
>These days, I expect a good compiler to at the very minimum support
>programmer-supplied inlining hints, and the Fortran, Pascal, and C
>compilers I normally use do it _automatically_.  This is another
>of those optimisations which has been known and used for decades in
>the Lisp community, which lets you write your program using a function
>call instead of a macro.  I guess inline functions are another
>"left-field optimisation".
>
>> For example, if someone does this:
>
>>void sub(char *s)
>>{
>>    ...
>>    if (strlen(s) == 0) {     /* check for null string */
>>        ...
>>    }
>>}
>
>>and they know it's stupid, but they also know the compiler
>>just happens to have optimization for it, should they
>>still be shot?  "Diana, get me my rifle."
>
>You have prejudged the issue by stipulating that the programmer
>doing this KNOWS it is stupid.  To start with, can I just make the
>obvious point that in a very large number of currently used languages,
>the direct equivalent of this would be the very best thing to do.
>There are a lot of *good* programmers out there (definition: in a
>reasonable amount of time they can write readable code that works)
>who would *not* "know that it's stupid".  It is, for example, much
>less stupid than writing
>	if (s == "") 
>
>Let's see what is good about this code:
> - it is correct (not a NULL test, not a "" test, but a length test)
> - it is clear (much clearer to people not immersed in C than "!*s")
>Doesn't look stupid to me yet.
>What's bad about it?
> - it takes O(|s|) time.
>BUT
> - standard optimisations like common subexpression elimination, can be
>   applied, so that any number of calls to strlen(s) without any
>   intervening potential change to s are no more expensive than a
>   single call
> - in many applications, all or a large part of s will be processed
>   if it is not empty, so the cost of sub() will be O(|s|) anyway
>so it's only "stupid" if it occurs in a loop and you know your
>compiler _doesn't_ move loop invariants out.

I Just wanted to point out that this rediculous conversation has taken
reality right out the window!

if(strlen(s)==0) 

is *NOT* functionally equivelent to 

if(s=="")

Wanna know why??

* It would only work if s could only represent string constants
and then only if the compiler removed duplicate constants! If a null string
were allocated with strdup("") then it's address would be somewhere else
entirely and the expression would fail.

The second expression compares the pointer s to the address of the string
constant "" (null string). If that constant resides in more than one place
in memory (because the compiler didn't remove redundant copies) then the
expression would fail even if it were "essentially" true.

-Pete

BTW: I find it good practice to put constant expressions on the left side of
comparisons to point out situations where I might forget one of the '='.