From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: Right shift Date: 17 May 2000 18:54:38 GMT Organization: Aachen University of Technology (RWTH) Lines: 53 Message-ID: <8fupte$pfv$1@nets3.rz.RWTH-Aachen.DE> References: <3922AD5F DOT EB45FD4D AT tiscalinet DOT it> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 958589678 26111 137.226.32.75 (17 May 2000 18:54:38 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 17 May 2000 18:54:38 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com >>Wrong question, sort of. > No. I wanted just to understand how does >> really works, so i used a > simple number. It's not the particular number you used. The thing is that there is is not really any way 'how >> really works'. There are lots of them, and it may depend on influences you never though about which of them will be used by your compiler next time you compile the same source file. >>It's better for your programming skills if you do not know how this is >>implemented, so you don't make any silent assumption that will break >>if your program ever gets moved to another compiler, operating system >>or machine. > My prog works perfectly, but, as i do not make any silent assumpion, i > was wondering how the da mn thing works, so i made a little test prog... If at all, you should have been looking at the assembly code generated by the compiler, not at the final output. Your particular application may benefit from using shifts instead of divides, but gcc is quite a clever optimizing compiler, so you should ask yourself: "Why didn't it do the same optimization?" Chances are it didn't because the optimization will break your program, as far as gcc can deduce from what your code says. Telling gcc more precisely what you want, like using unsigned variables, instead of signed ones, here, might have yielded the same speed increase, without breaking the cleanness of the program. > About my prog skill: if i must improve (and i must) let me learn. You misunderstood my mention of programming skills, I think. I didn't imply yours has to improve. What I wanted to point out was that knowing this particular detail will not improve your programming skill at all. It'll leave it unchanged, or even deteriorate it. >>Ignorance can protect you, sometimes. > I prefer knowledge (do you like aphorisms?) There is no fact to know, there. If you memorize a particular implementation's behaviour, that 'knowledge' will become 100% useless as soon as your compiler, or your CPU architecture, or any of a number of possible other influences changes. Such information is not 'knowledge', it's useless trivia, in almost all applications. Learning such knowledge usually leads to silent, unconscious assumptions based on it, later, which wreak havoc on your programs, instead of improving them. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.