From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public From: SYS0.MICRO-NEIL.COM@ (madscientist) Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/08/26 Message-ID: <4vt4qs$eb5@news1.mnsinc.com>#1/1 X-Deja-AN: 176627421 distribution: inet references: <31FBC584.4188@ivic.qc.ca> <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> <4uah1k$b2o@solutions.solon.com> <01bb853b$ca4c8e00$87ee6fce@timpent.airshields.com> <4udb2o$7io@solutions.solon.com> <01bb8569$9910dca0$87ee6fce@timpent.airshields.com> <4urqam$r9u@goanna.cs.rmit.edu.au> <01bb8b84$200baa80$87ee6fce@timpent.airshields.com> <4vbbf6$g0a@goanna.cs.rmit.edu.au> <01bb8f18$713e0e60$32ee6fce@timhome2> <4vroh3$17f@goanna.cs.rmit.edu.au> organization: Micro-Neil Systems reply-to: peter.mcneil@micro-neil.com newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-08-26T00:00:00+00:00 List-Id: In <4vroh3$17f@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: >"Tim Behrendsen" 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 '='.