• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Collapse

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on "Who'd be a game dev..."

Collapse

  • aussielong
    replied
    Originally posted by SupremeSpod View Post
    You're damn right I wouldn't, you wouldn't make it past DodgyAgent.
    Good comeback!

    Leave a comment:


  • SupremeSpod
    replied
    Originally posted by aussielong View Post
    Right shifting a negative signed integer is undefined. Or rather , the result is platform and compiler dependent.

    You wouldn't be interviewing me pal.
    You're damn right I wouldn't, you wouldn't make it past DodgyAgent.

    Leave a comment:


  • aussielong
    replied
    Originally posted by SupremeSpod View Post
    So, by your logic...


    unsigned int a = 4;

    a = a >> 1;

    The answer could be unpredictable? Sorry mate you failed the interview.
    Right shifting a negative signed integer is undefined. Or rather , the result is platform and compiler dependent.

    You wouldn't be interviewing me pal.

    Leave a comment:


  • SupremeSpod
    replied
    Originally posted by aussielong View Post
    It doesn't matter if you are only after the lower bits. It's faster than padding unnecessarily.

    Another bloke who does not know his limitations.
    So, by your logic...


    unsigned int a = 4;

    a = a >> 1;

    The answer could be unpredictable? Sorry mate you failed the interview.

    Leave a comment:


  • aussielong
    replied
    Originally posted by d000hg View Post
    I think it's a bit over the line trolling on technical stuff like AL is doing, people might think he's correct and muck up their work!
    Get orf moi laaand!!

    Leave a comment:


  • d000hg
    replied
    I think it's a bit over the line trolling on technical stuff like AL is doing, people might think he's correct and muck up their work!

    Leave a comment:


  • chef
    replied
    I'm with DA on this one, reading this thread is interesting but also completely over my head. Can someone give a small example of >> << <<< and >>> in some code please so I have a better chance of actually keeping up

    Leave a comment:


  • aussielong
    replied
    Originally posted by SupremeSpod View Post
    How can you leave the top bits undefined? You'd **** the value up.

    Spod - In "I ******* Despair" mode!
    It doesn't matter if you are only after the lower bits. It's faster than padding unnecessarily.

    Another bloke who does not know his limitations.

    Leave a comment:


  • SupremeSpod
    replied
    Originally posted by aussielong View Post
    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!

    Leave a comment:


  • aussielong
    replied
    Originally posted by VectraMan View Post
    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.
    Last edited by aussielong; 15 August 2012, 17:10.

    Leave a comment:


  • Bunk
    replied
    Originally posted by VectraMan View Post
    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.

    Leave a comment:


  • d000hg
    replied
    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.

    Leave a comment:


  • VectraMan
    replied
    Originally posted by aussielong View Post
    >> 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.
    Last edited by VectraMan; 15 August 2012, 12:07.

    Leave a comment:


  • EternalOptimist
    replied
    Originally posted by DodgyAgent View Post

    Leave a comment:


  • DodgyAgent
    replied

    Leave a comment:

Working...
X