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 18:19:49

On 05/10/2010 03:27 p.m., Christian Holmquist wrote:
> On 5 October 2010 12:55, Fernando Cacciola<fernando.cacciola_at_[hidden]>wrote:
>
>> On 05/10/2010 01:09 p.m., Jeffrey Lee Hellrung, Jr. wrote:
>>
>>> On 10/5/2010 8:57 AM, Fernando Cacciola wrote:
>>> [...]
>>>
>>>> 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)
>>>>
>>>
>>> What about "null references"?
>>>
>>>   What about it?
>>
>>
>> --
>>
>>
> It's convenient to pass optional values as pointers, even though one would
> much prefer passing them as optional references.
>
> void foo(Data* output)  // no way to tell if implementation supports the
> output to be null
> void foo(optional<Data&>  output) // clearly the intention is that the output
> is optional, and that the implementation is responsible for checking if
> output is assigned by caller or not
>
> optional<T&>  could unless I'm mistaken remove the member boolean, since
> there is no such thing as a null reference.
>
Ok, yes, in that case there is no possible doubt about the semantics, so the 
boolean can be spared.

OTOH, is such a corner case that I don't imagine myself doing it in the sort term.

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