Say I had a really performance-critical loop in my program where I need to check if a point was inside a rectangle, but I know at compile time that the lower bounds are always g
Maybe...
Whilst on "paper" this would seem to allow you to perform only two comparisons rather than four (which is nice) - you cannot guarantee how this will perform. Most CPUs these days can perform multiple parallel operations simultaneously - and the four comparisons you have are easily computed in parallel.
Your question depends on compiler, CPU and also the code before and after the check - so my answer is "maybe".
Avoid casting x,y to a type that is of a different size than what they currently are - i.e. cast from int8_t to uint8_t is fine, int8_t to uint32_t might incur a penalty.
Rewriting as you desire:
if ( ( static_cast<uint8_t>(x) < width ) &&
( static_cast<uint8_t>(y) < length ) )
Testing the performance delta is quite difficult, you will need to wrap your code with some assembly using the RDTSC instruction to catch the time before and after. You will likely also need to use the CPUID instruction to flush the pipeline as well.
In short, to me your optimization seems reasonable, but probably won't yield much if anything. It will work though.
Yes, it's a perfectly valid optimization when you're testing a signed integer and the lower bound is zero. In fact it's such a common optimization that your compiler will almost certainly do it automatically; obfuscating your code by doing it yourself is very likely to be a pointless premature optimization.
I just tested this on GCC 4.9, and confirmed by inspecting the generated assembly code that it performs this optimization automatically at -O1
and above. I would expect all modern compilers to do the same.