Re: [boost] [gsoc] Pointer Plus Bits Behavior and Interface

Subject: Re: [boost] [gsoc] Pointer Plus Bits Behavior and Interface
From: Andrew Sutton (andrew.n.sutton_at_[hidden])
Date: 2010-07-15 10:55:20

> Pointer Plus Bits: Is a data structure which points to specifically aligned
> object such that the value of the address is divisible by a power of two
> (the power of two which it is divisible by is given as a template
> argument).
> The empty bits of the pointer are then used to store extra boolean values
> relating to something (This is of the programmers choosing but it would
> seem
> best practice to make it related to the object being pointed at).
>

Hi Brian,

> 1) Should the pointer_plus_bits have a pre and post increment and decrement
> ( what about supporting other arithmetic operations such as add, minus, add
> assign etc...) ?
>

1.a) If this is a behavior supported by the pointer_plus_bits should it keep
> the bits being stuffed or set them to zero each time?
>

I don't think this class implement arithmetic operations because the extra
bits typically apply to the referenced object and not the pointer itself.
Here you have a case where the pointer and value type can't be arbitrarily
decoupled (the pointer is part of the value) and so these operations don't
make much sense.

> 2) Should the bits being stuffed apply during comparison?
>

Contrary to what I've just said, you could implement comparisons using the
pointers alone and excluding the bits. I think this would be reasonable.
Consider a comparison to nullptr (or (void*)0).

> 3) Should the pointer provide compatibility between itself and pointer of
> the same type that is being stuffed (the behavior of this would mean
> masking
> out the pointer so the stuffed bits won't apply during the comparison)? (ie
> Should pointer_plus_bits<T,2> be comparable to T* ?)
> (in pointer_plus_bits 2 is the number of bits being stuffed).
>

In general, I would say no.

I think a non-explicit constructor taking T* and a get() member should be
sufficient. I think that should cover most of your interoperability
concerns, but I'm just guessing here.

Andrew Sutton
andrew.n.sutton_at_[hidden]