setting a bit doesn't work

[Poseidon]

what's wrong with this piece of code to set bits.. when i make from a zero-bit a zero-bit it makes a 1 bit from it..

Code: Select all

int set(int value, int bit, char newvalue) {
    int retval;
    
    int mask = 1 << bit;
        
    if (newvalue = 1) {
        retval = value | mask;     
    } else {
        retval = value & ~mask;    
        
    }
    
    return retval;        
}    

thanx in advance..

[Candy]

what's wrong with this piece of code to set bits.. when i make from a zero-bit a zero-bit it makes a 1 bit from it..

Code: Select all

int set(int value, int bit, char newvalue) {
    int retval;
    
    int mask = 1 << bit;
        
    if (newvalue = 1) {
        retval = value | mask;     
    } else {
        retval = value & ~mask;    
        
    }
    
    return retval;        
}    

thanx in advance..

It's very obvious if you don't use basic or other similar languages.

Try to compile with extra warnings turned on, and be prepared to slap yourself in the face.

For gcc, -Wall -Werror -W -pedantic -pedantic-errors turns on pretty much enough errors to make even the better looking code show its shades.

[Poseidon]

nope.. got the error myself

Code: Select all

if (newvalue = 1) {

you see..? only one =, instead of two :-[

[Candy]

Code: Select all

if (newvalue = 1) {

you see..? only one =, instead of two :-[

Seeing my first two comments, I saw it too but didn't think just telling you would be fair ... In basic you do comparisons with a single equals too, same as with SQL. Now, I usually get errors with SQL where I don't expect them...

[Poseidon]

took me an hour or so to find out.. you would think after years programming experience you wouldn't make such a mistake ???

[Candy]

took me an hour or so to find out.. you would think after years programming experience you wouldn't make such a mistake ???

Actually, I do. After years of programming you most of all learn to avoid complex mistakes. You will never learn to avoid the simple ones, but compiler warnings take care of them. They explain why I can develop at a pretty nice speed, they just plain warn me about anything.

FYI, my most common mistake is "Undeclared variable: i".

[proxy]

some people like to put constants on the left side of comparisons for this very reason for example:

Code: Select all

if(0 == ptr) {

}

this way if you accidentally forget one of the = then you will get an error about trying to assign to an r-value.

it's a stylistic thing, but can be useful

proxy

[Brendan]

Hi,

I'm wondering what sort of code the compiler generates for this - might be better to use inline assembly (BTR and BTS instructions)...


Cheers,

Brendan

[distantvoices]

= or == in c/c++/java and the like I always check first, if some condition doesn't work althou I've deliberately set all the parentheses and curly brackets in correct order - Not as If one immediately sees it.

I've read over your piece of code the first time and simply assumed there were == in the conditional expression - and so /dev/brain gave me two. Such a shame *gg*

the biggest trap as candy says are the all so evident looping variables - and suddenly one is outta scope and the compiler complains - oh, how can you even dare to use that i - and you 've got a hard time finding what's going wrong.

[Candy]

Just for testers: two pieces of code with a hard error to find. First took me two hours, second I didn't find (but it wasn't my problem, the other guy did find it after 2-4 hours):

Code: Select all

int main() {
    // This code strips the input of ;, / and \
    while(true) {
        char input = read_input();
        if (input != '/' && input != ';' && input != '\\') {
            output(input);
        }
    }
}

The error of the compiler is the very last line, that curly bracket isn't allowed to be there.

Code: Select all

int calculate_value(int input1, int input2) {
    int toreturn = 12 * input1 + 0.75 * input2 //* interest calculation, must also divide by the amount of months */ constant1
        + 14; /* constant adjustment for flaw in input */
    return toreturn;
}

The compiler didn't give an error, but the C++ compiler did something other than the C compiler used before. What?

[edit] Ok, the first example featured TWO errors. One was my own in retyping the error, and the second hasn't even been spotted. [/edit]

[B.E]

You could use a xor to do the same thing. you colud use:

Code: Select all

int set(int value, unsigned char bit)
{
   __asm
   {
    mov cl,bit
    dec cl
    mov ebx,1
              shl ebx,cl
    mov eax,value
    xor eax,ebx
   }
}

[distantvoices]

If knowing something's wrong there, it's not that hard.

in first example:

Code: Select all

  int main(void); // that looks really like a declaration, so no 
                      //wonder the compiler bails out.
  int main(void){ ... } // that's the expected way  *gg*

in second example, the c++ compiler will find that there is something to comment out after "* input2". It won't get any division to execute and will continue with "+ 14 ;" *gg* THe moral of the story: never ever place comments inside a line of code, only after the concluding ; *gg* But I admit, upon first look and if desperately searching, one would overlook those simple things as /dev/brain tells "This can't be, so it isn't"

[B.E]

Just for testers: two pieces of code with a hard error to find. First took me two hours, second I didn't find (but it wasn't my problem, the other guy did find it after 2-4 hours):

Code: Select all

int main();
    // This code strips the input of ;, / and \
    while(true) {
        char input = read_input();
        if (input != '/' && input != ';' && input != '\\') {
            output(input);
        }
    }
}

The error of the compiler is the very last line, that curly bracket isn't allowed to be there.

Code: Select all

int calculate_value(int input1, int input2) {
    int toreturn = 12 * input1 + 0.75 * input2 //* interest calculation, must also divide by the amount of months */ constant1
        + 14; /* constant adjustment for flaw in input */
    return toreturn;
}

The compiler didn't give an error, but the C++ compiler did something other than the C compiler used before. What?

corrected:

Code: Select all

int main(){
    // This code strips the input of ;, / and \
    while(true) {
        char input = read_input();
        if (input != '/' && input != ';' && input != '\\') {
            output(input);
        }
    }
}

The starting curly bracket of the main fuction is missing and the semi-colen should not be there

Code: Select all

int calculate_value(int input1, int input2) {
    int toreturn = 12 * input1 + 0.75 * input2 /* interest calculation, must also divide by the amount of months */ constant1
        + 14; /* constant adjustment for flaw in input */
    return toreturn;
}

the error is on the second line the extra "/". the compiler would ignore any after the "//". so Constant1 is ingored. another error is the line must funish with an operator to continue on the next line

[distantvoices]

@be: the formula should be:

Code: Select all

toreturn = 12 * input1 + 0.75 * input2/ constant1+ 14; 

one could also leave a simple space between the two slashes. then the compiler recognises old c style comment again.

[Solar]

some people like to put constants on the left side of comparisons for this very reason for example:

Code: Select all

if(0 == ptr) {

}

Do that in a project where you work together with me and I'll have to do you serious bodily harm.

You are checking whether the pointer is zero, not whether the zero is pointer. The compiler is your friend, enable whatever warnings it can give you, and please do not serve the computer, make the computer serve you.

I hate it when people use hard-to-read syntax for claims of "safety" or "efficiency". Unless you're really, really down core and know that strange syntax is the solution for an existing problem, I claim that code must be easy-to-read for humans, not for computers. Not when -Wall would solve the problem just as well.