quote:Original post by milo

As to the recompile issue when adding a field. So what? You going to rebuild something to to add another constant defined for a particular bit.

You seem to consider a recompile to equal a total rebuild? Chances are, there are more files that are dependent on that class definition than there are files dependent on the constants. Maybe you have some ninja PC where a full rebuild doesn''t bother you Some of us have to wait 20m to an hour to rebuild stuff

quote:The union idea is just a way to get both access methods when you need it.

I prefer to have 1 flexible interface rather than 2 interfaces, one for each need. This comes down to personal opinion and code style though.

quote:If you don''t need multiple non-contiguous bit setting for the bit fields, the bitfields and bitmasks are exactly the same after compilation(yes I''ve checked this, but maybe you know an example where this isn''t so).

Hmm, I don''t think I said anything about speed or optimization. If it seemed that way, it shouldn''t do. Yes, the 2 methods should work out the same. My preference is based on the interface and the compilation dependencies.

quote:My experience (both for work and fun programming) has been that I have rarely have a situation where a single decision in the code results in the setting more than one bitfield. I definitely find bitfields the more elegant code style.

And I''ve found loads of times when I want to set more than 1 bit at a time. Or to store a certain permutation of bits as a constant. That''s not so easy with plain bitfields. If you used the union method, and you add a new flag, you have to add the flag to the class and to some enum/const int somewhere, otherwise your union access will go out of sync with your bitfield access.

quote:
I don''t find myself worrying about internal representation either. Writing ''states.ThisState = 1;'' seems pretty simple and clear to me. Hell, so does ''states.AnotherState = 2;'' when using a 2 or more bit bitfield. Now that 2nd is a bit more painful () with bitmasks.

Surely the whole point of modern programming is to move away from wondering about internal representation? I''d use a member function such as TheObject.SetState(1..4) and then the class internals can set it. In this case, bitmasking would be fine since there are so few permutations and they can all be easily encapsulated.

quote:
At work experience tells me that average programmers (which is not me by the way) have more problem with bitmasks than bitfields. Their just easier for former COBOL programmers to get confused on.

Well, this is just down to the individual coder. As I''ve said, I often have reason to use multiple bits, or store them, and once you write the 3 or 4 wrapper functions to access the bits, it''s simple enough.

quote:Actually this points out the biggest flaw with C/C++ in my mind. So much flexibility actually gets in the way sometimes for interprogrammer discussions/code sharing/etc. Damnit, code my style!

Well, yes And I have to work for a company that has no code standards... *sigh* with Visual Basic... *double sigh*