Mail Archives: djgpp/2000/05/17/16:45:41
>>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.
- Raw text -