From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-11 16:23:47
----- Original Message -----
From: "Tanton Gibbs" <thgibbs_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Wednesday, December 11, 2002 5:22 PM
Subject: Re: [boost] Formal review: Optional library
> > optional<int> opt0(1);
> > optional<int> opt1(2);
> > (opt0 == opt1) // true
> I would not have any problem with this returning false.
This would return false only if it compares values,
but it would return true if it compares initialization states.
I see that (opt0==opt1) makes sense to compare true when
both are uninitialized if this comparison is defined
to compare initialization states.
However, William suggests that relational operators for optional can be
defined to compare values, not initialization states, with just the
clause that comparing a value against nothing (for equality) yields false.
This is the model followed by NANs, and is perfectly well defined.
My problem is that even though it is well defined, and known think,
I just don't find this definition usefull; I don't want this comparison to
I want it to be undefined.
Anyway, I still owe William a concrete example to show why this definition
is not usefull; though I would conversely like to see an example were it is.
> In the normal ptr
> char c, d;
> char* p, *q;
> p = &c;
> q = &d;
> if( p == q ) // false
> People expect it to compare memory locations, not initialization status.
Right, and memory locations have nothing to do with pointee-values:
char c = 1 :
char d = 1 ;
char* p = &c, *q = &d;
( p == q ) // false even though (*p == *q) is true
char e = 1 :
char f = 2 ;
char* r = &r, *s = &f;
( r == s ) // still false even though (*r == *s) is false
As you can see, relational operators in optional, if they follow the
definition suggested by William, break pointer semantics
because they would be comparing values (pointee) which is
totally unlike pointers (you don't compare pointee values when comparing
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk