Re: [boost] compact_optional -- prompting interest

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

On 27 September 2015 at 17:20, Matt Calabrese 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 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