Re: [boost] compact_optional -- prompting interest

Subject: Re: [boost] compact_optional -- prompting interest
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-09-27 17:12:28

On 27.09.2015 23:45, Matt Calabrese wrote:
> On Sun, Sep 27, 2015 at 4:23 AM, Andrey Semashev <andrey.semashev_at_[hidden]>
> 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.