At present there's a strong possibility that the compiler does not optimise fixed points defined with a zero-width fraction part due to the extra operations required for fractional fixed points.
Although I think it's unlikely that anyone would actually want to use a fixed point with a zero-width fraction part (because this would be more or less equivalent to an integer of the same size), I think it would be good to specialise this case at some point on the off chance that there is a genuine need for such types given that there's a clear way to optimise in this situation.
In particular, some of the possible optimisations are:
getInteger() can avoid shifting by simply returning this->value.getFraction() can avoid shifting by simply returning 0.- Multiplication and division do not need to upscale and downscale.
roundFixed() and similar functions could simply return their argument.
At present there's a strong possibility that the compiler does not optimise fixed points defined with a zero-width fraction part due to the extra operations required for fractional fixed points.
Although I think it's unlikely that anyone would actually want to use a fixed point with a zero-width fraction part (because this would be more or less equivalent to an integer of the same size), I think it would be good to specialise this case at some point on the off chance that there is a genuine need for such types given that there's a clear way to optimise in this situation.
In particular, some of the possible optimisations are:
getInteger()can avoid shifting by simply returningthis->value.getFraction()can avoid shifting by simply returning0.roundFixed()and similar functions could simply return their argument.