3 ms·

At least in C++, wouldn't you just write these "hacks" only once, in inline methods of a BitField class? It's much more likely to mistype state = state & ~BI

At least in C++, wouldn't you just write these "hacks" only once, in inline methods of a BitField class? It's much more likely to mistype state = state & ~BIT7; than to mistype state = state.without(BIT7);

dahfizz 9y ago
Would you create a wrapper class and member function to make addition less likely to mistype? num = num.plus(x); might be less likely to mistype than num = num + x; but nobody would ever do that. Once you've done bitwise operators a few times they become just as comfortable and natural as addition or subtraction.
daemin 9y ago
Nope, people actually just write the bit setting code. It's simpler and also I haven't found a good generic bit flags class that works as you intend.
- slededit 9y ago
  What about C++ bitfields? Not a library but a language extension. A lot of code I used has migrated to that.
  - daemin 9y ago
    Normal C++ bitfields? Sometimes you get that inside classes in the form of "bool x : 1; bool y : 1;" etc. But that's much harder to use as far as function parameters go, so old school bitmasks are used for that.
scraft 9y ago
As daemin says, no, I am used to working with people that find basic bit field manipulation easy to work with[1], so there isn't any confusion. Plus there are performance concerns. I remember one graduate introducing a c++ bit field class and tried to replace some core functionality with it and killed performance. Developers prefer to debug non optimized builds, and non optimized builds can end up running slow when you replace simple one liners with classes and inline methods that don't get optimized in debug builds. [1]I hope this doesn't sound aggressive as it really isn't intended to. It is just everyone is so used to seeing bitwise operations it is as straight forwards as reading "set the third bit" or "toggle the last bit" when we see the C code.
coldacid 9y ago
I'd only do that if I could force every compiler to _always_ inline those methods. The cost of a method call for a simple bit operation is magnitudes greater than just doing the operation itself (tens to hundreds of ops versus 1-5).

dahfizz 9y ago

Would you create a wrapper class and member function to make addition less likely to mistype? num = num.plus(x); might be less likely to mistype than num = num + x; but nobody would ever do that. Once you've done bitwise operators a few times they become just as comfortable and natural as addition or subtraction.

daemin 9y ago

Nope, people actually just write the bit setting code. It's simpler and also I haven't found a good generic bit flags class that works as you intend.

slededit 9y ago
What about C++ bitfields? Not a library but a language extension. A lot of code I used has migrated to that.
- daemin 9y ago
  Normal C++ bitfields? Sometimes you get that inside classes in the form of "bool x : 1; bool y : 1;" etc. But that's much harder to use as far as function parameters go, so old school bitmasks are used for that.

scraft 9y ago

As daemin says, no, I am used to working with people that find basic bit field manipulation easy to work with[1], so there isn't any confusion. Plus there are performance concerns. I remember one graduate introducing a c++ bit field class and tried to replace some core functionality with it and killed performance. Developers prefer to debug non optimized builds, and non optimized builds can end up running slow when you replace simple one liners with classes and inline methods that don't get optimized in debug builds. [1]I hope this doesn't sound aggressive as it really isn't intended to. It is just everyone is so used to seeing bitwise operations it is as straight forwards as reading "set the third bit" or "toggle the last bit" when we see the C code.

coldacid 9y ago

I'd only do that if I could force every compiler to _always_ inline those methods. The cost of a method call for a simple bit operation is magnitudes greater than just doing the operation itself (tens to hundreds of ops versus 1-5).