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. / Christian