Who'd be a game dev...

[d000hg]

Maybe it was an addition to a non-standard C compiler... as >>/<< map directly to SHR/SHL (or is it SAR/SAL?), >>>/<<< mapped to ROR/ROL.

[aussielong]

Maybe it was an addition to a non-standard C compiler... as >>/<< map directly to SHR/SHL (or is it SAR/SAL?), >>>/<<< mapped to ROR/ROL.

>> is from C++, I don't recall seeing it in C but I haven't programmed in C for 15 years so I could be wrong. I don't think it's used much because the compiler should do it for you these days anyway and I guess with fast hardware these days, getting the last millisecond performance out of the code is not most peoples concern.

[aussielong]

Whoosh.

Which language is it has >>> and <<< which does a shift with wrapping?

>>> is C++ too. I think it similar to >> but one pads with 0 and one doesn't. Java is going back to C++ with increasingly complicated and ugly syntax.

[DodgyAgent]

[EternalOptimist]

[VectraMan]

>> is from C++, I don't recall seeing it in C but I haven't programmed in C for 15 years so I could be wrong.

You are wrong.

I don't think it's used much because the compiler should do it for you these days anyway and I guess with fast hardware these days, getting the last millisecond performance out of the code is not most peoples concern.

How do you tell the compiler to do a bit shift, other than using the bitshift operators? And then what does it optimise it to?

>>> is C++ too. I think it similar to >> but one pads with 0 and one doesn't. Java is going back to C++ with increasingly complicated and ugly syntax.

Well now you're just making stuff up. What does it pad with if it's not 0? 1?

If it's a signed value, and you shift right, it pads with 0 if positive or 1 if negative. If it's unsigned, it pads with 0. Java seems to have two seperate >> and >>> operators, for some inexplicable reason.

[d000hg]

Was ANY part of AL's post accurate

Although a compiler COULD change a multiplication/division into a shift operation if it wanted to, if you are multiplying by a constant e.g x *= 32.

[Bunk]

You are wrong.



How do you tell the compiler to do a bit shift, other than using the bitshift operators? And then what does it optimise it to?



Well now you're just making stuff up. What does it pad with if it's not 0? 1?

If it's a signed value, and you shift right, it pads with 0 if positive or 1 if negative. If it's unsigned, it pads with 0. Java seems to have two seperate >> and >>> operators, for some inexplicable reason.

If it's the same as Javascript then the >>> pads it with zero whether it's positive or negative, hence it's the unsigned right shift operator.

[aussielong]

You are wrong.



How do you tell the compiler to do a bit shift, other than using the bitshift operators? And then what does it optimise it to?

Well now you're just making stuff up. What does it pad with if it's not 0? 1?

If it's a signed value, and you shift right, it pads with 0 if positive or 1 if negative. If it's unsigned, it pads with 0. Java seems to have two seperate >> and >>> operators, for some inexplicable reason.

These operators make it fast to multiply and divide by powers of 2, which can be done using others operators, clearly. Some compilers will replace a multiply by 2 with a bit shift to the left.

You get 0 padding if you use >>>, I think with >> you don't... Which leaves the top bits undefined after the shift.

This shouldn't be in general really should it.

[SupremeSpod]

These operators make it fast to multiply and divide by powers of 2, which can be done using others operators, clearly. Some compilers will replace a multiply by 2 with a bit shift to the right.

You get 0 padding if you use >>>, I think with >> you don't... Which leaves the top bits undefined after the shift.

How can you leave the top bits undefined? You'd **** the value up.

Spod - In "I ******* Despair" mode!