I think there is no redundancy here, as all three variables are checked to be within the range from 1 (inclusive) to 1000 (inclusive). This requires 6 comparisons in total, i.e. two comparisons per variable: one comparisons to check the lower bound of the variable, and then another comparisons to check its upper bound.
Still, you could rewrite the code using pre-processor macros:
Note: After macro expansion, this code will be no different from your original code. So it only makes to code "look" cleaner (more readable), but it does not reduce the number of comparisons.
______
Of course, you also could write an actual function to check the range for each variable:
you can make it shorter and less easy to understand, eg
if(n1*n2*n3 && ...) //cleans up the zero checks
or split it up:
if(n1 && n1 <1001)
if(n2...
but no matter what you do here, you are just making the c++ pretty. Most of your choices will have no real impact in making it 'better' in terms of function, and what you have is fairly readable
though you may consider breaking it up a bit visually.
that is pretty. But does it do more work? I can't tell easily. Adding function overheads or checking everything before stopping or whatnot makes it easy to accidentally get the answer with several extra steps, just to rearrange the code a little (again, the original was not awesome but not that bad either). Like the min/max version is super clean but it for sure has 1 extra comparison I believe at best, and 3 extra (because lack of short circuit) at worst (??) if I did that right in my head.
Like the min/max version is super clean but it for sure has 1 extra comparison I believe at best, and 3 extra (because lack of short circuit) at worst (??) if I did that right in my head.
The min/max version has six comparisons (exactly the same as the others): 2 implicit ones in each of min and max and 2 in the comparisons with 0 and 1001.
It has a single && operation (as compared to 5 in the original).
But I doubt that any of the codes took any measurable amount of time.
Its main deficiency over an in_range() function is that the range might have been different for each variable - in which case it wouldn't have worked.
yes, I guess I was saying the min max have to do all the checks, while the straight up version can stop if one is out of bounds directly.
No, its not important generally, unless the fixed comparison is in a gigantic loop (clearly not, here).
Right, its not general purpose. Thats ok if you think its unlikely to change, its tighter than the GP ones.
In a check such as (x >= 1) vs x > 0, even though the former has short circuiting it is probably more efficient to implement the latter?
With (x >= 1) it checks x>1 before x=1?
How do you insert left-side spaces on this forum without it left shifting the empty spaces?
with optimizations on, it is likely smart enough to do 1 check here, eg < 2
short circuiting correctly is difficult. You honestly need to know what case is most likely to fail and check that first, and this can be consistent or random or vary from user to user etc. Hardware helps with branch prediction somewhat anyway, but that is more limited than people like to admit: it does not do that much for a complex condition with lots of terms that can't be optimized to just a few terms.
you can't do spacing without using a tag. The output, code, and other tags let you have spaces and indentation for code or even just to make a point. Regular post text does not have it.
The compiler will generate code to compare x with 1 and then one instruction for the branch. Something like:
1 2
cmp eax, 1
bge L1
It doesn't first check for greater-than and then check for equal.
The cmp sets the flags accordingly and then the following branch instruction checks these flags and branches accordingly depending upon the set flags and the particular branch instruction used.