I'm the helpline operator and I'll spare you the time

[venta]

Note to self:

3 + 8 << 2

is not the same as

3 + (8 << 2)

That's an hour you just spent tracking down a bug based on a mistake you've made several times before.

Yes, I know, brackets. Normally I'm assiduous about brackets. But for short lines like, say,

3 + 8*2

I actually think they detract from readability.

I'm sure there are sound reasons why shift has precedence over addition in C, but I find it counter-intuitive in the extreme.

Maybe a nice dose of online mockery will help me remember in the future :(

Note to non-geeks:
Don't worry, not much to see here. I made a school-boy error.

Comments

[beckyc.livejournal.com]

If it makes you feel any better, today I spent half an hour wondering why a function always returned false. Then I noticed that on Friday, I had commented out a line of code. Duh!

[boyofbadgers.livejournal.com]

If it's any consolation, I suspect most C, C++ or Java programmers have done the same thing at some point. I know I have, and am super assiduous about bracketing bitshifts as a result. Not that I end up using them that often, which I suspect is the source of the problem in the first place.

[venta.livejournal.com]

Yes. In conversation last night, several of us agreed that perhaps in this day and age << should be reserved for conceptual bitshifts, and if you're just shifting to get a cheap multiply then just use * and assume the compiler will sort it out :)

(I think this error was indeed introduced because I changed a *7 to a *8, and instinctively altered it to a <<3. Which I'm quite sure our compiler is smart enough to do for me, anyway.)

[boyofbadgers.livejournal.com]

Aye, if a modern compiler didn't do that automatically when needed I'd be very surprised. I think the only place I've used a bitshift explicitly for a division or multiply recently was in some audio code, where I wanted to suggest that the operation had to be as efficient as possible.

[venta.livejournal.com]

I wanted to suggest that the operation had to be as efficient as possible

Interesting. I'd never really thought about the choice of syntax indicating subtle meaning to future readers. So much more sophisticated than comments ;)

[bateleur.livejournal.com]

No, you're right, it's counter-intuitive.

I have a natural defence against making this error, though. I am so bad at remembering precedence that the version of the line without parentheses reads like an error to me purely for not having them!

[venta.livejournal.com]

Yes, I finally managed to formalise my confusion as follows.

3 + 2*4 != 3+2<<2

Would you bracket

x = 3 + 2*4

?

[bateleur.livejournal.com]

Would you bracket x = 3 + 2*4?

Depends on the circumstances. I wouldn't in a case like:

position + 4*increment

...but I would for something like:

(width1 * height1 * depth1) + (width2 * height2 * depth2)

The approximate rule being something to do with the length of the resulting term rather than anything intrinsic to the mathematics. (Note also my use of spaces to imply the expected precedence, as you have done in some cases too.)

[venta.livejournal.com]

... so the fact that your natural defence would have saved you must rely on your viewing << in a different light from * ?

If I could remember not to treat it the same, I wouldn't be in this mess ;) As it is, my shift was a very short line, so just got spaces to clarify its intended operation.

[bateleur.livejournal.com]

For me I think it's more that the familiarity of ops involving only * and + make them an exception which don't say much about other cases. In particular, the fact that * (or 'x') is often elided in mathematical writing makes it more natural to me to write 8*foo than foo<<2.

Of course, this does mean I'm vulnerable to messing up the precedence of something like foo^2, but fortunately it both binds very tightly and is seldom used!

[ewx.livejournal.com]

Your compiler doesn’t warn you about that one?

[venta.livejournal.com]

I don't think so, no.

I concede that the someone-else's-code I'm porting generates so many warnings that I may have missed it, though. I really must do that trawl through and try to obliterate the warnings for fear I'm missing useful ones :(

[ewx.livejournal.com]

Ah yes, code not already warning-clean can be a nightmare to tidy up l-(

If it isn't in BODMAS, be afraid.

[fractalgeek.livejournal.com]

Brackets are your friend.

I believe the logic is, twiddling bits is considered higher priority than assembling them into a bitmask. So build your mask, shift it into position, then OR the mask together.

Re: If it isn't in BODMAS, be afraid.

[venta.livejournal.com]

You see, if I remembered that it wasn't BODMAS, there wouldn't be a problem :) As far as I'm concered << and * are basically the same operation, making it an M.

[d-floorlandmine.livejournal.com]

Glad I've never had to fuss with bitshifts.

Then again, I'm mostly working with Access and VB ... so I can generate my own cockups.