if (a == 0 && b == 0) {}


if (a + b == 0) {}

What do you think is more readable? Is there any (performance) difference in the compiled programme?

For a and b >= 0.

  • 21
    a=-1, b=1

    Have you thought about it?

    Update: now you have
  • 6
    a+b is prolly better speed (thinking of it in assmebly, 2 compares vs 1)

    for reading - depends on whos reading.

    there's 2 types of ppl in this world, those who can extrapolate from incomplete data
  • 2
    @ruhe No, I forgot. Thanks for mentioning! I added a restriction to the post.
  • 1
    @zlice Indeed, the second one has one compare less than the first one, but therefor an addition that the first one hasn't.

    And even with more variables, for every less comparation there will be an addition in assembly.
  • 3
    @Benedikt just tested w/ gcc,

    #include <stdio.h>

    #include <stdlib.h>

    int main() {

    unsigned char a = rand();

    unsigned char b = rand();

    if (a == 0 && b == 0)

    printf("0 one\n");

    if (a + b == 0)

    printf("0 two\n");

    return 0;



    with -O2 it compiles to a single compare for ==0 && == 0 anyway

    edit: for reference, it basically simplifies a ==0 && b == 0 to ---> (a|b) == 0
  • 4
    more readable you say?
    I'd go with this:

    if(!(a-b!=0 || a>0)) {}
  • 2
    @ruhe i need to do something where i just bloat everything like this. it's so ugly.
  • 0
  • 1
    @nik123 that's horrible for portability
  • 0
    Complete condition is different. What if a==-b?
  • 1
    @pnpninja in assmebly i dont think that matters

    00000000 | 1000000 = 1000000 and should not trigger a zero

    OP said for >=0 (lol face)
  • 1
    @zlice please explain why? Logic level/architecture issue?
  • 2
    @nik123 i just know from experience. i think some of it is arch and some of it is compiler.

    like the 00000000 | 10000000 not being 0

    00000000 && 10000000 half passes

    checking 0 && 0 you have to make sure non-negative. & isn't great for checking 0. want !(a&&b) for 0 but then a half pass would be !FALSE. or make weird logic to understand you want 0s. pretty sure every arch (mips/arm/x86&64) all have OR and some kind of "jump/branch if zero compare"

    i dont have the code on this machine but i wrote something a bit back where i did the "a && b" and had to change it.
  • 1
    I assume the top one is quicker because the second check will not be done if the first one fails.
  • 2
    @Codex404 nope. a compare and a jump take a few cycles and/or/add/sub/mul(usually) all take 1 cycle. so you do the 1 cycle and 1 compare/jump either way, top (without compile optimize) will try to compare to 0, maybe jump, compare to 0, jump to where it wants.
  • 1
    @zlice so it doesn't work for signed variables

    edit: I've never thought about it, now I'll have to watch out for all the potential bugs I have laying around in my code.
  • 5
    Wow it is really rare to see a dev who cares about performance at this extent, very good.

    if(a==0 && b==0) will take 3 cycles at worst, 2 at best ( where a is 0, it will skip b==0 part but still gonna JMP anyways )

    if(a+b==0) would take 1 cycle, but poor readability since an outsider wouldn't realize natural number guaranteed parameters right away.

    if(a&&b) Sounds good, doesn't work. Plus poor readability. 1 cycle but pass.

    I would go for first option, since it doesn't require any comment to explain what is going on. I think most of the time, 2 extra cycles won't hurt much.
Your Job Suck?
Get a Better Job
Add Comment