It is always difficult to give just the “best” solution (better in what respect - lines of code, readability, speed of execution, number of bytes of machine code instructions ...?), But since you are asking about speed of execution in this case, we can focus on this .
You can enter this variable that you propose and use it to reduce the conditions to simple, less than the conditions, as soon as the answer is known. Less than conditions trivially translate into two machine code commands on most architectures (for example, CMP (cf.), followed by JL (jump, if less) or JNL (jump, if not less) on Intel IA-32). With little success, the compiler will notice (or you can do it yourself, but I prefer clarity, which has the same pattern everywhere), that trues < 2 will always be true in the first two if() operations and will optimize it.
int trues = 0; if (trues < 2 && condition1) trues++; if (trues < 2 && condition2) trues++; if (trues < 2 && condition3) trues++; // ... if (trues >= 2) { // do something }
This, as soon as the answer is known, reduces the possible complex evaluation of conditionN to a simple smaller one than the comparison, due to the logical short circuit of most languages.
Another possible option, if your language allows you to use a logical condition for an integer, is to use it to reduce the number of lines of source code. However, you will still evaluate each condition.
if( (int)(condition1) + (int)(condition2) + (int)(condition3) >= 2) {
This works on the assumption that casting the boolean value FALSE to an integer results in 0, and the result of TRUE results is 1. You can also use the conditional operator for the same effect, although keep in mind that it may introduce additional branching.
if( ((condition1) ? 1 : 0) + ((condition2) ? 1 : 0) + ((condition3) ? 1 : 0) >= 2) { // do something }
Depending on how smart the compiler optimizer is, it can determine that as soon as any two conditions evaluate to true, the whole condition will always be evaluated as true and optimized based on this.
- Please note that if you have not really profiled your code and identified it as the culprit , this is probably a case of premature optimization. Always strive to ensure that code is read by human programmers in the first place and quickly executed by a second computer, unless you can show conclusive evidence that the particular piece of code that you are looking at is the actual performance bottleneck. Find out how this profiler works and uses it well. Keep in mind that in most cases, the programmer’s time is much more expensive than the processor’s time, and smart methods take longer for the maintenance programmer to analyze.
- In addition, compilers are really smart pieces of software; sometimes they actually discover the intent of the written code and may use specific constructs designed to speed up these operations, but rely on the fact that they can determine what you are trying to do. A great example of this is replacing two variables using an intermediate variable, which on IA-32 can be done using
XCHG , which excludes the intermediate variable, but the compiler should be able to determine that you are actually doing this, and not something smart, which may give a different result in some cases . - Since the vast majority of written implicitly deferred software spends most of its life in maintenance mode (and a lot of the written software that was written was lively and well last year than previously thought), it makes sense to optimize for maintainability if it does not bring unacceptable costs in other respects. Of course, if you evaluate these conditions a trillion times in a tight loop, targeted optimization can make sense very well. But the profiler will tell you exactly what parts of your code need to be carefully studied in terms of performance, which means that you avoid unnecessarily complicating the code.
And the above warnings said that I am working on a code that has been making changes lately, which at first glance will almost certainly be considered premature detailed optimization. If you have a high performance requirement and using a profiler to determine which parts of the code are bottlenecks, then optimization is not premature. (However, they may be dishonest depending on the specific circumstances.)