Optimization of if

[Richard Heathfield]

Christopher Layne said:

Do you like pain?

Why do you ask? It looks self-documenting and pain-free to me.

 

[Chris Dollin]

In commercial SW, multiple statements/expressions on a line are neither
clearer nor more "compact".

They look clear and more compact to /me/.

The layout above is horrible

It's spelt b e a u t i f u l.

and totally debugger unfriendly.

Never been a problem for me.

The excessive whitespace breaks the flow of a code
read.
Maybe.

the lack of indentation doesnt hilite the conditional
assignments.

Who cares?

0 out of 10.

It's the pointless variable I hate and despise.

 

[Chris Dollin]

Do you like pain?

MYOB.

Did you have a constructive comment to offer?

 

[¬a\\/b]

No, just write clearer and more compact code:

int retval;

if (X) retval = retval1;
else if (Y) retval = retval2;
else if (Z) retval = retval3;
else retval = 0;
return retval;

what says compiler about this:
return X?retval1:Y?retval2:Z?retvalz:0:0:0;

 

[Chris Dollin]

what says compiler about this:
return X?retval1:Y?retval2:Z?retvalz:0:0:0;

It says it's a syntax error, and I agree with it.

 

[¬a\\/b]

It says it's a syntax error, and I agree with it.

and what says about:

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#define uns unsigned

uns fn(uns x,uns y,uns z){return x?1:y?2:z?3:0;}

int main(void)
{uns x, y, z;

srand(time(0));
x=rand(); y=rand(); z=rand();
printf("fn(%u, %u, %u)=%u\n", x, y, z, fn(x, y, z));
printf("fn(%u, %u, %u)=%u\n", 1, 0, 0, fn(1, 0, 0));
printf("fn(%u, %u, %u)=%u\n", 0, 1, 0, fn(0, 1, 0));
printf("fn(%u, %u, %u)=%u\n", 0, 0, 1, fn(0, 0, 1));
printf("fn(%u, %u, %u)=%u\n", 0, 0, 0, fn(0, 0, 0));
return 0;
}

"return x?1:y?2:z?3:0;"
seems more clear than
"
if(x) r=1;
else if(y) r=2;
else if(z) r=3;
else r=0;
return r;
"

 

[Chris Dollin]

and what says about:

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#define uns unsigned

uns fn(uns x,uns y,uns z){return x?1:y?2:z?3:0;}

It says "stupid #define `uns`.

"return x?1:y?2:z?3:0;"
seems more clear than
"
if(x) r=1;
else if(y) r=2;
else if(z) r=3;
else r=0;
return r;
"

Well, I think so too. Of course the code /I/ showed was (a) right
the first time, (b) preserved the OPs names for values, (c) exploited
whitespace, (d) carried an explicit "your layout may vary" message,
and (e) appeared yesterday.

Below you will find some whitespace you may care to use in your code,
and some dontdefines you may find useful.

.
.
.
.
.
.
.
.

#dontdefine uns
#dontdefine f
#dontdefine u
#dontdefine r
#dontdefine w
#dontdefine ll
#dontdefine p

 

[Richard Bos]

It says "stupid #define `uns`.

Interesting. Mine says: "Don't reply to trolls, please."

Richard

 

[Richard Bos]

if(X)
{
return retVal1;
}

if(Y)
{
return retVal2;
}

if(Z)
{
return retVal3;
}

[...]
As others have noted, you're missing a default value.

Try this:

retval=default_value;
if (Z) retval=retval3;
if (Y) retval=retval2;
if (X) retval=retval1;
return retval;

That's likely to be (slightly) *less* efficient, since it can assign
to retval multiple times. It can also behave differently if X, Y, and
Z are expressions that depend on each other's evaluation; for example,
evaluating Y might not work if X hasn't already been evaluated.

True. But at least it does have the sacred One Return Statement, and
doesn't have the Scary else Keyword.

I'd probably lay it out that way if the conditions and result
expressions really were that terse, except that I always put a blank
after an "if" (it's not a function call, so it shouldn't look like
one):

So would I, and I did in the code above which I retyped rather than
copied-and-pasted. For the same reason as you do, BTW.

But in real life, everything is likely to be longer, perhaps too long
to fit on a single line. And if the conditions really were "X", "Y",
and "Z", I'd seriously consider using names that make some actual
sense.

They'll often be longer, but not always. I've not infrequently had code
where the conditions were something like

if (x<0) x=0;
if (y<0) y=0;
if (x>size) x=size;
if (y>size) y=size;

In context, those x and y did make sense: they were cartesian
coordinates. Possibly they were start_x and start_y, plus end_x and
end_y.

Richard

 

[CBFalconer]

.... snip ...

In commercial SW, multiple statements/expressions on a line are
neither clearer nor more "compact". The layout above is horrible
and totally debugger unfriendly. The excessive whitespace breaks
the flow of a code read. the lack of indentation doesnt hilite
the conditional assignments. 0 out of 10.

If you have to use a debugger on the above snippet, there is
something seriously wrong with your reading comprehension. You are
obviously a slave to poorly thought out so called 'coding
standards'.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[¬a\\/b]

Below you will find some whitespace you may care to use in your code,
and some dontdefines you may find useful.

.
.
.
.
.
.
.
.

#dontdefine uns

better u32? better i32?
why not?

#dontdefine f
#dontdefine u

is it not good define "f" and "u" because there is some relation in
language constant like to write "a=282u;" or "b=878.8f;"?
(what is wrong? "8u" is a word and not 2 words so #define should not
apply there)

#dontdefine r
#dontdefine w
#dontdefine ll
#dontdefine p

don't know why all others are not ok ( in the case these defines are
in all sources the same defines)

 

[Dave Hansen]

Pretty common style idiom for extremely simple maintenance logic. Get used to
it. Obviously for a more complex case that is not filled with rudiment, you
will see multiple lines. I just think you're pissed off at the "style"
itself.

I wouldn't inflict the above on my maintenance programmers,
particularly if X, Y and Z are less trivial than implied. But I'd
probably only add whitespace and some sensible indenting.

The coding standard of my present employer requires braces on all
conditional blocks and loops (thankfully not switch cases as well).
There are rational reasons for this requirement, so I grit my teeth
and follow it. I pick my fights more carefully. I'm even getting the
C++ guys to use PC-lint now. And they're discovering some interesting
things about their code...

Regards,
-=Dave

 

[Jamie Boy]

Rajen:

if(X)
{
return retVal1;
}

if(Y)
{
return retVal2;
}

if(Z)
{
return retVal3;
}

How do i Optimize this? Please give me some suggestions.

Put the one which is most likely to be true first. Failing that, I think your
code is at optimal efficiency.

 

[Christopher Layne]

Do you like pain?

Alright, old article, but I just couldn't resist. I know some of you will get
a kick out of this:

http://thedailywtf.com/Articles/Turn_it_up_to_Eleven.aspx

 

[Dietmar Schindler]

Rajen:



Put the one which is most likely to be true first. ...

That can change the behaviour if more than one of X, Y, Z is true and
retVal1, retVal2, retVal3 are different.

 

[Christopher Layne]

That can change the behaviour if more than one of X, Y, Z is true and
retVal1, retVal2, retVal3 are different.

Excepting *exceptions*, the most common case should go first. The goal is to
get a hit asap.

 

[Keith Thompson]

Excepting *exceptions*, the most common case should go first. The goal is to
get a hit asap.

That's *a* goal, but it doesn't make a whole lot of sense to optimize
the performance of your code at the cost of breaking its semantics
(unless you just want to get your wrong answers as quickly as
possible).

 

[Christopher Layne]

That's *a* goal, but it doesn't make a whole lot of sense to optimize
the performance of your code at the cost of breaking its semantics
(unless you just want to get your wrong answers as quickly as
possible).

That's where the "exceptions" part came in.

e.g.

if (k > 40) return 2;
else if (k == 45) return 3; /* exception to above */

^^ NOT what I recommend.