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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: Joe Keane Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/09/01 Message-ID: <50blgc$g9f@shellx.best.com>#1/1 X-Deja-AN: 177798277 sender: jgk@best.com references: <31FBC584.4188@ivic.qc.ca> <4vroh3$17f@goanna.cs.rmit.edu.au> <01bb9360$21d0dbe0$87ee6fce@timpent.airshields.com> <50650h$rek@goanna.cs.rmit.edu.au> summary: It's bad code. organization: none keywords: efficient newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-09-01T00:00:00+00:00 List-Id: In article <4vroh3$17f@goanna.cs.rmit.edu.au> Richard A. O'Keefe 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" 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 Mark Wooding 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 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