Re: [boost] compact_optional -- prompting interest

Subject: Re: [boost] compact_optional -- prompting interest
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2015-09-27 18:20:20

On Sun, Sep 27, 2015 at 3:08 PM, Nevin Liber <nevin_at_[hidden]> wrote:

> On 27 September 2015 at 15:45, Matt Calabrese <rivorus_at_[hidden]> 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 <nevin_at_[hidden]> 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