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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk