Boost logo

Boost :

Subject: Re: [boost] [optional] Specializing optional to save space
From: Nevin Liber (nevin_at_[hidden])
Date: 2015-09-27 17:47:45


On 27 September 2015 at 16:19, Andrey Semashev <andrey.semashev_at_[hidden]>
wrote:

> On 27.09.2015 23:38, Nevin Liber wrote:
>
>> On 27 September 2015 at 15:03, David Stone <david_at_[hidden]> wrote:
>>
>> Andrzej posted another thread about creating a new compact_optional class.
>>> The goal of this class is to make it easy to create a new optional type
>>> with a special sentinel value. This allows easy customization per
>>> instance
>>> of an optional value.
>>>
>>> This post is about the opposite approach: making it easier to specialize
>>> optional to provide special behavior for all instances of a given
>>> optional
>>> type.
>>>
>>> When I bring this up, people often compare it to the vector<bool>
>>> specialization, but this is a completely different issue.
>>>
>>
>>
>> No, it's the same issue. It'll have subtly different behavior. Generic
>> programming counts on the behavior being the same.
>>
>> The only reason vector<bool> is bad is because of its spelling. Had it
>> been a different name, most people would be happy.
>>
>> optional<T> controls the lifetime of T. If you have a sentinel instead,
>> then the lifetime of the engaged T is exactly the same as the lifetime of
>> optional<T>.
>>
>
> I got the impression that the OP intended that the specialized optional<>
> still controlled the lifetime of the adopted object the way it does now.
> The proposed change basically offloads engagement checking to a
> user-specializable trait but really nothing more than that.
>

His example was to use a specific value of std::string::size() as a
sentinel. How does that work with his specialized optional if the
specialization is orthogonal to lifetime control? Feel free to assume
string and optional<string> are friends, as well as a specific
implementation of std::string.

-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  (847) 691-1404

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