Re: [boost] compact_optional -- prompting interest

On Sun, Sep 27, 2015 at 3:08 PM, Nevin Liber wrote:

On 27 September 2015 at 15:45, Matt Calabrese wrote:

...

For instance, I have a "card" type that I use for representing one of 52 possible playing cards. It takes up a byte, even though a byte can hold more that 52 different values. If I put a card in an optional as-is, then it's occupying extra space for the discriminator. I'd like to use optional to represent "not-a-card" because had I baked a "not-a-card" value into the original type itself, then any function that takes an actual card would need an additional precondition and I'd likely want to assert to make sure that the card is valid. With an intrusive_optional abstraction, it makes it easy to just use the spare storage in the byte in order to represent not-a-card only when it is needed, and it takes up no extra storage than what the base abstraction does.

So, your card type already has a disengaged state it knows how to deal with. Why then do you need to wrap your card type inside another template?

No, in other words you cannot construct a card with a not-a-card state. Internally there is obviously room in storage to represent it, since we are only using 52 values on the possible set of values that can exist for a byte, but with just this abstraction there is no valid way to get there. On Sun, Sep 27, 2015 at 3:08 PM, Nevin Liber wrote:

And if it doesn't understand the disengaged state, then you have to break a class invariant (the "byte" being in the range 1..52) to do it, which just doesn't work.

It doesn't. The idea is that the times that you can make such a hook for intrusive_optional are where it is not UB to access that storage regardless of whether or not the object is constructed. For instance, I use an unsigned char to store the value 0 through 51 and I know that this is at the start of the storage location for the card. As the creator of the card type I can guarantee this (this is why it is intrusive). With that knowledge, I can provide some small, default set of functions that operate on raw storage (not an instance of the card type) but that can do so safely whether the object is constructed or not since I can also via hooks guarantee that there will be an unsigned char in that location regardless. -- -Matt Calabrese