Wizard1988

I just stumbled upon this page: Bitwise Tricks and thought it was really interesting. What do you guys think?

__________________

Dameon

To be used when needed, not to make things fancy but hard to read.
A few, such as number & 1 to test even/odd, I deem straightforward enough for every day use. Others may break at some point in the future, in an entirely unforeseen and puzzling way. Which may not be worth it to save a cycle in a function that gets called twice a week.
So, as with just about everything, it's a tradeoff. Picking up cool tricks is easy. The hard part is knowing where they fit.

And then, there's stuff like this...
http://www.beyond3d.com/content/articles/8/
That's the kind of optimization worthy of praise.

__________________
MD5(sig) = bcef75433db02e9ad9bf81d6f7c5c270

null_ptr0

grats on figuring out an age old set of usages of the standard binary/bitset operations that replace the use of memory consuming 'booleans' in java.

Jabo

It's interesting that, although the subject was touched upon in school, we were told it's usually not a good idea to use bitwise operations. Guess that's what I get for getting an associates at ITT?

DaWei

If your compiler optimizes a mod-two operation into a bitwise operation, then you're good to go. If it doesn't, it's a waste. Many people don't even realize there's an alternative. A highly-skilled programmer realizes there is an alternative, and a highly-skilled programmer is not flabbergasted and helpless if he or she sees if (!(a & 1)).

Admittedly, I'm no longer an embedded programmer working with tiny amounts of resources. Consequently, I no longer look to see if a multiplication or division involves a power of two. In the first place, that number might change, someday, to a non-power of two, and my code would break.

I would also offer the opinion that if one is resorting to these kinds of tricks, from necessity, then one might wish to drop into assembly language and avoid the extraneous stuff that a compiler routinely emits.

On the other side of the coin, a programmer can be a good, productive programmer without knowing what goes on under the hood.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Wizard1988

I also hear that allot of tricks like this pop up on interview tests. The way some of these tricks work is common sense, but like Dameon said figuring out where they fit is the hard part.

Easy logical operator trick


If you know any other interesting tricks please share

Also if anyone is really interested in things like this I suggest reading "Computer Systems - A Programmers Perspetive" by Randal Bryant and David O Hallaron

__________________

DaWei

There's no seg fault there because there's no dereference. The fact that a is NULL (false) shortcircuits the evaluation so that (*a = 10) is neither assigned nor evaluated.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Dameon

@Wizard

I wouldn't call that a...trick. Especially not a 'bitwise' trick. Logical AND (&&, not &) does not need to evaluate the right side because there's no way that an AND could be true if the left is false. Notice the 'true' and 'false' -- the logical operators work with booleans. Bitwise AND on two integers (such as 0 & 15) behaves in a somewhat similar way but in an entirely different fashion. If you consider 0 as false, then 0 & 15 will yield false as expected, but only because AND was performed on the two sets of bits. Your example might be filed under basic understanding of the language.

__________________
MD5(sig) = bcef75433db02e9ad9bf81d6f7c5c270

Wizard1988

Yes, I understand that that wasn't a bitwise trick. What I was trying to demonstrate is that there are things which are common sense but applying them in the right place is what is hard as you have said.

__________________

Harakim

You don't need the 'if': a && *a=10;
However, that usually boils down to: 'if (a) *a = 10;' anyway