Subject: Re: [boost] [optional] memory use for optional refs and ptrs
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2010-10-05 14:27:25
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk