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

[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 ;)