Zitat von Andrew Sutton <andrew.n.sutton@gmail.com>:
Would it be better to make the pointer_plus_bits convertible to a boolean based on the value of the pointer being stored? This would allow it to be more like to a pointer being that you could, as many people do, put it inside of an if statement to check to see if its null.
No. One could argue that the bits should be evaluated to produce the Boolean result as easily as evaluating the pointer. There are two aspects in pointer_plus_bits and they shouldn't be obscured or conflated.
I strongly disagree with using views in the design of this data structure. It's not such a complex concept that you would need to explicitly decouple its concerns via views. You end up designing a pointer+bits that can't be used natively as a pointer or bits.
The data structure is pointer_(plus_bits). First and foremost, I would expect its instances to model (at least some) Pointer semantics, which
I could agree with that given the name "pointer_plus_bits". but it seems to me that the underlying generic is something like "bitfield_tuple". so "pointer_plus_bits" could easily be an adapter (not: view) to this underlying and provide an interface to the pointer part by default, if you want to be able to write "if(p)". but the problem remains that a bitfield tuple or pointer plus bits are 2 separate logical variables (...the purpose of this library) and the user needs a way to differentiate between the interfaces to the two. obvious example: pointer plus an integer of 3 bits. operator++ could increment the pointer/iterator, or increment the integer. IIUC all you're saying is that you want a type that provides a view to the first part by default, and to the second on request.
includes "if(p)" and not "if(pointer_view<...>(p))". Dereferencing the
probably more like "if(p.pointer())" which would return the pointer view. (or "if(p)" if pointer_plus_bits is an adapter as described above.)