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.

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.

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.

What about C++ bitfields? Not a library but a language extension. A lot of code I used has migrated to that.

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.

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).