Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-07-28 18:12:42


Hi,

I'm reading a draft of a proposal to standarize interval arithmetic (from
the authors of Boost.Inverval).
They propose to include the specialization "interval<bool>" to represent
"false<->maybe<->true", that is, a tristate boolean expressed as an interval
in the "lattice" range [false,true]

They specifically mention that they propose interval<bool> instead of
Boost.TriBool becasue they argue that conversion from indeterminate to bool
shouldn't be false but fail with an exception.
It turns out that in any actual case I can think of, throwing when trying to
narrow an indeterminate tribool into true or false is indeed much prefered
than returning false.

The tribool documentation says that you should write:

if ( b )
  certainly_true();
else if (!b )
   certainly_false();
else uncertain();

The authors of the proposal argue that even though you should follow that
pattern, if you don't, so your code
is written like:

if ( b )
     certainly_true();
else certainly_false();

then if b is indeterminate the false branch should not execute because
that's hardly what the programer intended in the case of a tri-state logic.

>From my own experience I cannot but agree. If you're implementing a complex
triboolean predicate that nests child triboolean predicates (various levels
down), you can rightly decide to use the simplified pattern (with just the 2
certain branches) and let the exception mechanisms wind up the "uncertain
answer" up to the caller; but for this you need ideterminate->bool to
fail...
Of course there is always the choice of using the "correct" pattern that
properly test for "certainly false".

So, why doesn't tribool throw in this case?

Fernando Cacciola
SciSoft


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk