But if you don't at least provide a boolean cast and a dereference operator, then I don't think you should be using "pointer" in the name of the class.
Meh, you could call it pointer_int_pair, and nobody would complain about the "pointer" in the name. (PointerIntPair is LLVM's version of this.)
You could if you were implementing a pointer/int pair, which is exactly what that data type does. This reinforces my point. I believe that you could use Brian's framework to create a typedef consisting of a compound pointer/bitfield representation and call it something similar. Regardless of its name it's still going to have a tuple-like or component-like interface to access the pointer and the bitfield. (Brian, please correct me if I'm wrong). I would think that the point of creating this particular data type (pointer_plus_bits) was to emphasize the pointer aspect and less so the "pair". If you really want a pointer/int tuple, then create one. If you want a pointer plus some bits, then I think this would be the place to look--but only if it worked more or less like a pointer. Andrew Sutton andrew.n.sutton@gmail.com