On 05/10/2010 03:27 p.m., Christian Holmquist wrote:
On 5 October 2010 12:55, Fernando Cacciola<fernando.cacciola@gmail.com>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