Boost logo

Boost :

Subject: Re: [boost] compact_optional -- prompting interest
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-09-27 07:23:24


On 27.09.2015 14:00, Matt Calabrese wrote:
> On Sat, Sep 26, 2015 at 1:12 PM, Nevin Liber <nevin_at_[hidden]> wrote:
>>
>> I'm strongly against the word "optional" appearing the name, for the
>> following reasons:
>>
>>
>> - optional<int> allows me to use every single value that can be stored
>> in an int. This doesn't.
>> - optional<string> allows one to shorten the lifetime of the string it
>> holds. This doesn't.
>> - optional<T> has a nothrow default constructor. This doesn't.
>>
>> At best, it resembles optional only superficially. Please give it a
>> different name.
>
>
> This. However, I do think that there is a place for a separate
> intrusive_optional as well, though the empty value should not be a valid
> value of the type, but rather, just be able to take advantage of its
> storage, and the type should not be constructed while the in the empty
> state. I.E. an optional reference only takes up the size of a pointer
> because it uses the "0" value for empty. Similarly, any type that contains
> a reference (or a pointer that cannot be null) also can take advantage of
> this by way of an intrusive optional. The user would have to provide a
> predicate that operates on the raw storage of the value, and access it in a
> way that is well-formed whether the object is constructed there or not, so
> it is a little bit trickier to specify properly.

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk