rbbb@rice.ARPA (David Chase) (03/14/85)
You people are crazed! TEN messages on string copying idioms in 5 days, all saying about the same inane useless thing. My stupid comments: 1) Of course it is better to use strcpy than to write it again and again yourself, and of course is more readable and right the first time. Of course, the piss-poor implementations of the standard library encourage recoding of library routines. 2) We run 4.2, and strcpy is NOT written in assembler. Bcopy and friends are written in assembler. 3) The DECUS C library version works only for strings smaller than 65k, but will work correctly when source and destination are overlapping (because movc3 works that way), unlike most implementations of strcpy that I have seen. Crappy library routines NOT written efficiently NOT written in a general way lead to private recodings of library routines. 4) Strlen followed by strncpy is not faster than strcpy because strncpy is defined to copy up to the null OR the nth character, whichever comes first. Perhaps you might try strlen followed by bcopy. 5) Register variables are a hopeless hack advertised as a feature by lazy-ass compiler writers. Even when I DO know which variables are more frequently used, I cannot achieve the same results as a worthwhile compiler that places a variable in a register only when it really needs to be there, and then (GASP!) puts SOMETHING ELSE in that same register. Before flaming at me that "the same code isn't efficient everywhere" and similar mindless drivel, perhaps you might consider the existence of TWO VERSIONS, one portable and exhibiting the defined behavior, the other written for a specific machine to run as fast as it possibly can (and ALSO exhibiting the defined behavior). There are lots and lots of companies out there selling Unix, and they can only gain by coding efficient machine-specific versions of library routines, because that will make their products run faster (and since the improvements are non-portable, no one else can pirate them, right?). Until programmers believe that the compiler will make their code efficient, and that the library routines are written as efficiently as possible, they will continue to play their narrow-minded, unmaintainable, non-portable small-scale efficiency-twiddling games. Hopelessly disgusted, more than I ever expected to be, David Chase, Rice University
mat@hou4b.UUCP (Mark Terribile) (03/20/85)
>5) Register variables are a hopeless hack advertised as a feature by > lazy-ass compiler writers. Even when I DO know which variables are > more frequently used, I cannot achieve the same results as a worthwhile > compiler that places a variable in a register only when it really needs > to be there, and then (GASP!) puts SOMETHING ELSE in that same register. >David Chase, Rice University The problem of deciding what to place in fast, easy-to-access registers is dependent on whether you need to optimize for space or speed, on which paths you expect to be be the most frequently executed, etc. When you can show me a compiler that can read the programmer's mind and be clairvoyant as well (to determine what the program's input will be) I will accept your advice. In the mean time, I welcome the chance to give the compiler hints as to what should be made easily addressable, though it would be nice to have it make a try if you don't. If you tell me that space is irrelevant, then I can only assume that your code will be running on machines that you don't buy. If you have to write code for an embedded application, and you expect to sell 100 000 of them, then you are damn well concerned with how little memory you can squeeze your code into. And if you are writing real-time applications, you sure do care about how fast things run. This is not to say that compilers shouldn't be better. They should. Most production compilers have some awful mishandling of some really simple cases. But why shouldn't a compiler be willing to take a little advice? If you want to bellyache, how about the hardware designers who make it easier to address this datum than that datum? Don't bother. There are engineering trade-offs, and unless you've done it once or twice yourself, please don't pontificate. As to sharing registers ... { register struct schmonk schp = exschmonk[ newschmonk ].next; ... } { register int n_widget; ... } 'nuf said? -- from Mole End Mark Terribile (scrape .. dig ) hou4b!mat ,.. .,, ,,, ..,***_*.