Bit fields, a componet which goes along with bitwise operators, are an important part of C(and C++). You can use them to save space: struct { UINT flag_a : 1; UINT flag_b : 1; } struct_name; (where as UINT is defined to be unsigned int). This is useful in saving memory, by combining many variables(flag_a and flag_b, in this case) together; we can do this because we only concern ourself with true/false value(0/1, respectively). In perl(as far as I know), you cannot do this automatically, but you can still make a scalar and use it to turn on and off certain values, and check certain values. For example: assume an eight bit integer(well, getting back to perl, scalar) 00000011 Here, we have the last two bits set. If we want to know if the second to last bit(i.e.,2nd rightmost) is set, then we can say: if(($scalar_here >> $number_to_shift_by) & $mask) #in this case, $number_to shift_by would be 1; and $mask would be a value such that all bits but the rightmost would be off; i.e., 00000001. To set the bit, we would say $scalar |= $mask, where as if we want to set the second right most bit, $mask should be a value where as all bits are off except the second right most: e.g., 00000010. We use or so that if it is on it stays on; however, if we want to say turn it on, except if it is already on, turn it off, we substitute |= with &=. Another use for bitwise operations is to substitute two values without using a temporary variable: e.g.,
#var1= 0011 var2 = 1100 (only stating last
# 4 bits, of cousre)
$var1 ^= $var2; # v1=1111
$var2 ^= $var1; # v2=0011
$var1 ^= $var2; # v1=1100

You can take a 32 bit int and set one of the bits. Setting the 4th bit would make the integer value 8. Now why would you want to do this? A good example of this would be the data that stored in Windows NT domain accounts. I use this example because its the most recent thing I've used bitwise operators for. If you look at NT accounts, there are several "toggles" for things like "Account Locked Out", "User Must Change Password", "User Cannot Change Password", etc...

Instead of storing all of these in seperate variables, they are all stored in one integer. And if you want to test to see if the users account is locked out or unlock the account, you can test for that bit or toggle the bit, respectivly.

In smaller programs, it's probably not something that you're going to want to use. But if you're talking about a bunch of simple yes/no variables that are going to be replicated over and over again (like for accounts), you're going to save space, and I belive slightly improve speed by storing them in an integer as on/off bits.

Hope this helps...
Rich

... and I belive slightly improve speed by storing them in an integer as on/off bits.

To my knowledge, doing that is actually slightly slower in most cases. This is because if you're storing it as an integer one operation must be done to retrieve it: get value from location in memory; and to store it: store value to location in memory. On the other hand, with indiviual bits there are more operations; to get a bit value: get 32 (or whatever) bit value from memory, and then use AND to check the bit's value; and to store: get value from memory, use OR or AND or XOR to set or toggle the bit in question, and then store the value in memory.

But it's probably unlikely that the speed difference will matter in most cases. I'd expect that usually the speed tradeoff is well worth the space advantage

(update:) Thinking about this more makes me think it more of a toss-up. You probably would have a speed improvement if you would otherwise have to get lots of values from memory, because that is relatively "slow". If you're just doing something like going through a bunch of these numbers to check for one or two bits, or to set one or two bits, the way of using lots of numbers will probably be faster, I think. But if you're just using one number for a bunch for a bunch of things you're using a runtime, I'd guess that it would be faster because you could actually keep the value in one register, or it would be easier to cache it. (With perl, we probably don't have any hope of it staying in a register, so the cache is your only hope; and the cache might just as easily cache 32 32-bit values, too.) (All this is of course IMO, and subject to being totally wrong.)