Thread: shift operator

I always heard people saying to divide by 2 right shift by 1 and so on and to multiply left shift by 1 and so on. But is so wrong because if we divide 5 you will only get 2 but not 2.5 and it is applicable to only to even numbers. Then why the above statement is said?

At the lowest level of optimisation, every modern compiler I've looked at produces exactly the same code for n / 2 and n >> 1 (and other divisions commonly done using shifts) where n is an integer anyway, so sacrifice readability to use something that you have to be careful to use to avoid implementation defined behaviour that will end up with the same result anyway without you having to worry about which cases are implementation defined (e.g. if n is a negative integer). The compiler will take care of it and optimise n / 2 to n >> 1 if it can.

Many years ago there was some justification for it, but even then you have to keep in mind that "pre-mature optimisation is the root of all evil". There are cases where using bitshifts are perfectly acceptable (or even more readable), but to divide by 2 is not (way more often than not) one of those cases.

>if we divide 5 you will only get 2 but not 2.5

Try to make the code so it will work with div/mult by 2/4/8/16
and you or the compiler will use right/left shift.

if you use numbers like *3 or *5 the compiler will most likely still just use 1 or 2 left shifts + original value.

div by 5, as integer don't have decimal point the result will be floored.
if you need decimal point, 32bit fixed point by Union could do it.

Code:

union{
 unsigned long myfixvar;
   struct{
   unsigned int myfixlow;
   unsigned int myfixhigh;
   }
 }