what meaning this code.

Hi my friends; i don't understand this code...

what meaning this code?

input_x = x_data[desc[1] & 0b00000011];  
if(desc[1] & 0b10000000)input_x *= -1;

Regards Murat

input_x = x_data[desc[1] & 0b00000011];

x_data is presumably a four element byte array.
So, set the variable “input_x” to the “desc[1] & 0b00000011"th element of “x_data”.
desc[1] & 0b00000011” will be a value in the range 0…3.

if(desc[1] & 0b10000000)input_x *= -1;

If the sign bit (bit 7) of “desc [1]” is set, negate the variable “input_x”

oh ok... very very thanks... I was about to go crazy :)

Regards.. Murat

if(desc[1] & 0b10000000)input_x *= -1;

That looks like the perfect way to write code that is difficult to get your head round

if(desc[1] & 0b10000000)
{
  input_x *= -1;
}

would at least separate the test from the action if true

Or, even more obviously

if(desc[1] & 0b10000000)
{
  input_x = -input_x;
}

input_x = abs(input_x);Does that negate input_x when input_x is positive ?

No, it negates x if x is negative, but leaves it positive if it is positive. Why? Where did "abs" come into the discussion?

UKHeliBob:

input_x = abs(input_x);

Does that negate input_x when input_x is positive ?

Nope, and it doesn’t execute when desc[1] is negative either. I didn’t read his question close enough. I deleted my wrong answer, but it looks like I wasn’t fast enough.

If it’d been written this way, the OP probably wouldn’t have needed to ask what it meant.

if(desc[1] < 0)
{
  input_x = -input_x;
}

BigBobby:
Nope, and it doesn’t execute when desc[1] is negative either. I didn’t read his question close enough. I deleted my wrong answer, but it looks like I wasn’t fast enough.

If it’d been written this way, the OP probably wouldn’t have needed to ask what it meant.

if(desc[1] < 0)

{
  input_x = -input_x;
}

But if “desc[1]” is a uint8_t, it can’t be less than zero.

AWOL:
But if “desc[1]” is a uint8_t, it can’t be less than zero.

True then this code would work whether desc is signed or unsigned or even an int.

if((signed)desc[1] < 0) input_x = -input_x;

I don’t understand why you don’t like the single line if though.

BigBobby:
True then this code would work whether desc is signed or unsigned or even an int.

if((signed)desc[1] < 0) input_x = -input_x;

I don’t understand why you don’t like the single line if though.

Because it reminds me of BASIC.
I still have the flashbacks - you weren’t there, man.

AWOL: No, it negates x if x is negative, but leaves it positive if it is positive. Why? Where did "abs" come into the discussion?

See post #7

I don't understand why you don't like the single line if though.

Because it does not separate the action from the test. I always put braces round the action even if it is a single statement. I find it easier to read and maintain and it is trivial to add statements to the action.

In the case of the line of code that started this discussion there was not even a space between the test and the action, which I suspect added to the OP's confusion.

The joke being that the oh-so-clever bit-fiddling to get the sign bit is probably slower than just ((signed)foo)<0), because there’s a machine-language opcode that checks the sign bit.

UKHeliBob: Because it does not separate the action from the test. I always put braces round the action even if it is a single statement. I find it easier to read and maintain and it is trivial to add statements to the action.

In the case of the line of code that started this discussion there was not even a space between the test and the action, which I suspect added to the OP's confusion.

Yes, the space goes a long way in the single line if statement. Much of the world shares your opinion about always including braces, and I'm with you for most things. Like I never do this (although I just received some code that did):

if(this)
  dothis();
else
  if(that)
    dothat();
  else
    donothing();

In some places it does seem clean though. Like this:

int dostuff(int address, int value)
{
  if(address > ADDRESS_MAX) return -1;

PaulMurrayCbr:
The joke being that the oh-so-clever bit-fiddling to get the sign bit is probably slower than just ((signed)foo)<0), because there’s a machine-language opcode that checks the sign bit.

Watch it turn out that the original poster’s code meant this and we all just assumed it was a sign bit:

#define INPUT_X_NEG_FLAG (0b10000000)
input_x = (desc[1]&INPUT_X_NEG_FLAG) ? -input_x : input_x;