Re: [boost] compact_optional -- prompting interest

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

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

> On 27 September 2015 at 17:20, Matt Calabrese <rivorus_at_[hidden]> wrote:
>
> > On Sun, Sep 27, 2015 at 3:08No, in other words you cannot construct a
> > card with a not-a-card state.
> >
>
> Except that every function in its implementation may assume the card is
> *never* in the not-a-card state.
>
> For instance, one could add ASSERT(1 <= cardIndex && cardIndex <= 52) all
> over the place, including in the beginning of the body of the destructor,
> and not expect anything to break.
>

That's still true. None of these asserts would fire. The value would only
ever be "0" (I'm assuming you are implying 0 is the empty state here) when
the card is not i na constructed state. In other words, if someone does:
"foo = nullopt", it internally checks via raw storage hooks if the object
is already logically nullopt, and if not, it destroys the card, and then
sets the value via the hook, which operates on raw storage.

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

> It isn't just about room.  The class has to know about it so that it can,
> at a minimum, weaken its invariants to support it.  And if you have to do
> that, I don't see any need for some generic class to wrap it.

No, it doesn't. That state will never be set while the object is in a
constructed state. That is what differs between this and compact_optional
(I'm off on a tangent in case that's not clear, and we could probably start
a different thread). The difference is in the nature of the hooks. These
hooks would deal with raw storage, and do not merely make the overall
optional "nullopt" by setting a value in the underlying object. Rather,
when setting to nullopt, the object itself is destroyed and we just re-use
the storage in a valid and non-conflicting way to identify that we are not
in a constructed state. We can check which state the overall object is in
(constructed or not constructed) regardless because the hooks operate on
raw storage, and with the knowledge that regardless of the underlying
object being constructed or not, there is (in this specific case) an
unsigned char in a very particular location.

-- 
-Matt Calabrese