From: Ulrich Eckhardt (uli_at_[hidden])
Date: 2005-07-16 03:19:53
On Sunday 10 July 2005 03:50, Jost, Andrew wrote:
> I am curious if there is support for what I'm calling a "dual_state"
> template class. Anyone familiar with Perl will instantly recognize the
> parallel. The idea is to attach a "statedness" value to arbitrary
> objects, allowing us to consider them defined or undefined.
[ snipped rest ]
I have one big concern that wasn't voiced in the whole thread yet: const
correctness. What I mean is, how does a const (ref to a) dual_state object
behave? What if I retrieve the value from such an object, will it modify that
object? Also, even for a non const object, I would be surprised if I just
retrieved the value and thereby changed the object.
In general, I wonder if you tried this already. I wouldn't be surprised if
using it turned out to be a bad or a good idea, but I don't think you can
determine the usefulness completely in the laboratory (i.e. on this ML). Many
concerns have been voiced already, in particular that it hides too much and
that it doesn't help writing correct code.
> I have not given any thought to
> what a dual_state<bool> is or how it is related to Boost.tribool.
dual_state<bool> x = ...;
if(x == true)
{ ... }
if(x == false)
{ ... }
if(x == undefined)
{ ... }
Problems here: 'x == true', how should that be evaluated? You can't first
perform a conversion of x to a bool, because then you would have to decide
whether that should be true or false. So, operator== needs to be overloaded
(among others) like this:
template<typename T>
bool operator==( dual_state<T> const& lhs, T const& rhs)
{ return lhs.defined() ? (lhs.get() == rhs) : false; }
template<typename T>
bool operator==( dual_state<T> const& lhs, undefined_type const& rhs)
{ return !lhs.defined(); }
I haven't looked at tribool too much, but it might be a good replacement -
there, too, the third state is not separate from the other states as it is
for boost::optional.
Uli