Paul Martz wrote: > Personally, I already feel that using an enum to store bitflags is > overkill. Defining an entire class to implement the bitflag/mask pattern > along with set/get methods strikes me as the epitome of C++ abuse. I > don't think I can back this, not even if measurements indicate no memory > or performance bloat. It's an unnecessary layer of obfuscation. > Using bitwise logic ops and unsigned bits/masks makes it perfectly clear > what is happening, even at the assembly level. It reduces the potential > for error and makes the code more readable.
Oh, I love getting to wrangle theory with friends. ;) Wouldn't you think, though, that some code isn't actually concerned with thinking about "bits", all it really cares about is "state"? Many times the bits in a bitmask are unrelated, and they're just grouped because you have several non-exclusive states you want to combine into a single member for storage efficiency. (I suspect the OptimizerOptions usage that originally spawned this discussion IS probably mostly-related state bits, so this may not apply). In the situation where they are unrelated state bits, being able to say stateBits.test(MY_STATE) it actually is perhaps more obvious and clear what's going on than doing it by hand with a bitwise operator. (I just can't resist stirring the pot... ;) > -Paul -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
