I was writing a tool that needed to check whether exactly one of a list of conditions was true. One way of doing this is to count them manually:
bool DoesExactlyOneConditionApply(DataSet data) { int count = 0; if (data.Widgets.Count == 1) { ++count; } if (data.Gadgets.Count == 1) { ++count; } if (data.Doodads.Count > data.Sockets.Count) { ++count; } if (data.Approvers.Contains(Approver.Director)) { ++count; } return count == 1; }
This works and is efficient, but is rather wordy and susceptible to copy/pasta bugs.
Performance was not an issue in this code because most of the time was being spent in calculating the DataSet, not in checking whether conditions apply.
Here’s what I came up with:
bool DoesExactlyOneConditionApply(DataSet data) { return new[] { data.Widgets.Count == 1, data.Gadgets.Count == 1, data.Doodads.Count > data.Sockets.Count, data.Approvers.Contains(Approver.Director), }.Count(v => v) == 1; }
This builds a temporary array that holds the results of each test, and we ask LINQ to tell us how many of them are true
.
A semi-straightforward translation to C++ (z/8hY9841j9), using Range-v3 in place of LINQ and
std::array
for the C# array, can generate reasonably efficient code that doesn’t use heap memory; GCC and clang can even break up thestd::array
and enregister all four booleans, so it doesn’t even use stack memory. (Semi-straightforward because godbolt’s version of Range-v3 doesn’t haveranges::contains
.)Unfortunately, neither GCC nor clang seems to be able to use the
[[gnu::pure]]
hint to optimize away calls when 2 trues have already been found (maybe that’s too tall an order, considering the amount of C++ machinery in Range-v3 that the compilers need to unravel first).Yeah. Can’t you just do that on one line, and possibly omit the ternary if true/false decay to 1/0?
And if you want to short circuit could also maybe use crazy parentheses to group statements with a logical operator that stopped evaluation if both sides are “1”.
I like Extension Methods for such things.
I also like generics. So when we put that together, we can write a generic extension method that can use any number of conditions:
It would be used like this:
As performance is not a requirement here but readability I think this should work quite well.
I like this one because it only checks as many conditions as it has to.
And it would be trivial to extend it to allow the number of wanted conditions to be a parameter.
Awesome, reminds me of the “good” “old” days of lisp/smalltalk.
I would name it slightly differently, such as OnlyOneOfTheseIsTrue
But it’s hard to beat a solution that’s a “one” liner, and where the function called doubles as a fairly complete comment about what’s being done/tested.
I would just use a boolean instead of an integer, IMO it’s easier to understand.
Not a one-liner. I’m just having fun.
Were I using a type-unsafe language, I would probably just write
Whether that would pass review is another matter.
(What is
Approver
anyway?)This definitely gets my “count”. plus easy enough to make it work where truth does not equal 1:
I have no problem with the performance hit of ray’s solution, as it’s almost certainly unmeasurable except if inside a loop. But I find this form clearer, personally. And I love collections where appropriate from my days of smalltalk and lisp coding.
At the cost of an array allocation and a delegate allocation and 4 invocations? No, thanks!
this comment has been deleted.
If you are in a tight loop, your code may be better overall. But if performance is not critical, readability trumps the runtime cost and your solution becomes horrible. Understanding your version takes more effort, and extending it is more error-prone.
Raymond has pointed out that performance wasn’t an issue in this case, so your “optimization” is actually a pessimization here.
Stack memory usage
You can also do a LINQ-less version:
How about
to return early as soon we know there are more than 1 values true?
// Ryan
Doesn’t help without other changes, because we’re making an array so all the values have to be computed regardless. Here’s what I came up with:
Yeah, the idea is the same.
I assumed they were not bools but still expressions/lambdas.
// Ryan
If the checks are expensive, or if the function is a performance bottleneck, I suppose one way to make it more efficient would be to bail out as soon as you see a second true condition
On the down-side, by removing function calls you risk breaking something.
It shouldn’t be true, but some people have written classes that actually mutate when you invoke a getter. Or perhaps `Data.Sockets` is lazy fetched on demand, and suddenly it’s not there as expected.
Can’t just go in all young programmer and say, “Pfft, look at how inefficient this is. I’ll just fix that up real quick.”
this comment has been deleted.