Re: [boost] [optional] memory use for optional refs and ptrs

Subject: Re: [boost] [optional] memory use for optional refs and ptrs
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2010-10-05 11:57:47

On 05/10/2010 11:11 a.m., Sebastian Redl wrote:
> On 05.10.2010 15:54, Krzysztof Czainski wrote:
>> 2010/10/5 John Reid<j.reid_at_[hidden]>
>>
>>> Rutger ter Borg wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm looking into boost::optional<> as a replacement for some of my code
>>>> which has to deal with optional values. However, it seems that cases which
>>>> are usually space-efficient optionals (e.g., ptrs in the form of a null-ptr)
>>>> do not have template specializations. In other words, boost optional
>>>> templates store a bool and the memory footprint of its template parameter,
>>>> regardless of type. I.e., optional references and pointers take their space
>>>> plus the space of an extra bool.
>>>>
>>>> Is there a reason for this?
>>>>
>>>> Might someone want to store a null pointer in the optional? I'm not sure
>>> about the references though.
>>>
>>> John.
>> I understand, that a null pointer means the same as lack of a pointer.
> In your use case.
>
> The idea has been discussed on the list before, and IIRC, the conclusion was
> that the library simply cannot rely on the user not wanting to have a null
> pointer in an optional.

Exactly.

optional<> cannot decide *by itslef* that a particular value happens to be 
equivalent to an uninitialized state. That is, a null pointer is not neccesarily 
the same as none. This is particulary true in a generic design when the type 
wrapped is unconstrained (i.e. T can be anything, including a pointer) and the 
condition of uninitialized state *must* be strict (i.e. not *any* value being given)

> I could see a trait for optional specifying if a type has a natural empty value,
> and if so, which.
>
This and other desirable policies has also been discussed, but the general idea 
of a policy-based design was rejected for this utility.
There where lengthly discussions about such designs for "simple wrappers" like 
shared_ptr<> or optional<> several years ago. The simple rational being that it 
clutters the compile-time interface.

-- 
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com