Of course, it's context dependent. As others mention, your code might be full of stuff like X / (divisor || 1).
Also, if loading total elements takes a significant amount of time, shouldnt this loading also be reflected in the progess bar?
X / (divisor || 1).
% cat >division.c <<EOF
#include <stdio.h>
int main(void)
{
printf("1/0 = %d\n", 1 / (0 || 1));
printf("1/2 = %d\n", 1 / (2 || 1));
printf("1.0/0 = %f\n", 1.0 / (0 || 1));
printf("1.0/2 = %f\n", 1.0 / (2 || 1));
}
% gcc -Wall -o divison divison.c
% ./divison
1/0 = 1
1/2 = 1
1.0/0 = 1.000000
1.0/2 = 1.000000
% python3
>>> 1 / (0 or 1)
1
>>> 1. / (0 or 1)
1.0
>>> 1 / (0 or 1)
1
>>> 1. / (2 or 1)
0.5
% python3
>>> 1 / (0 or 1)
1.0
>>> 1 / (2 or 1)
0.5 x / (divisor ?: 1)C doesn't have booleans and treat them as integers 0 or 1, it can do the math and will always return 1.
https://en.cppreference.com/w/cpp/language/implicit_conversi... (under "Integral promotion")
And C has a boolean type as of C99.
Defining x / 0 = 0 gets this behavior for free, while leaving zero as an exception means it has to be caught for every single signal calculation, which is a pain when there are potentially dozens of different signals, all of which are counting different things (and have different divisors). I've actually defined a helper function to do this automatically, which also lets me change the default "null object" easily if I choose a different representation or want to apply some baseline value.
Unless you're using unsigned ints, the discontuity will exist no matter what you do, because of negative divisors.
You say that you frequently have to write your little shim but honestly I don't remember writing code like that in recent memory.
You talk about progress bars, I suppose it makes sense if you somehow try to copy 0 elements for instance, and you end up dividing by zero when computing the progress, like:
And both copied_elems and total_elems are zero. But in this case wouldn't you want the computation to return 100% instead of zero?It's also a bit odd because it introduces a discontinuity: as the divisor goes towards zero the result of the operation gets greater until it reaches exactly zero and it yields 0. Wouldn't it make more sense to return INT_MAX (for integers) or +inf for floats? If you're writing a game for instance it might work better.
I guess it just goes to show that it probably makes a lot of sense to leave it undefined and let people write their own wrapper if necessary to do what works best for them in their given scenario.