Re: [boost] compact_optional -- prompting interest

On 27.09.2015 23:45, Matt Calabrese wrote:

On Sun, Sep 27, 2015 at 4:23 AM, Andrey Semashev wrote:

...

If the empty state of intrusive_optional means the governed object is not constructed then the usability of this tool will be significantly reduced. Defining the policy of empty state detection would require intricate knowledge of behavior and binary layout of the adapted type, including ABI details such as padding and vtable/virtual inheritance table pointers. For instance, you wouldn't be able to use intrusive_optional with std::string.

Right, which is why you wouldn't use such an an "intrusive_optional" template in that specific case (if you made a string type you certainly could use it, though). I'm not saying intrusive_optional would replace your template,

That's not my template, it's Andrzej's. :)

I'm just agreeing with others that if you do use one of the existing, valid values for the type, it's not really the same kind of abstraction as optional, even though it is useful, so it should probably just have a different name. Places where something like intrusive_optional (which is similar to your type, but more akin to optional) are useful are with types that you have control over.

I suppose you could draw analogy between intrusive_optional & optional and intrusive_ptr & shared_ptr. Fair enough, intrusive_optional requires some amount of control over the adopted type, similar to intrusive_ptr. What's different is the amount of hackishness that is required to support intrusive_optional. intrusive_ptr does not require you to work with the raw storage or know the binary layout of the object while intrusive_optional does. As much as I like the idea of reusing the storage for discriminator, this just feels too fragile to me. Maybe if there was a safer interface for supporting intrusive_optional in user defined types it wouldn't feel that way.