While diving down into the edges of Boost, I came upon the tribool class, which is a “header only” library. Tribools are bools with 3 states, true, false, and indeterminate. At first, this seems like an unlikely candidate for a general purpose library. However, upon some reflection, there are many cases where such a condition could arise:

  • Hasn’t been initialized yet – you might default something to false, but if its state truely isn’t know yet and it wouldn’t be semantically correct to indicate the false condition, then indeterminate could make sense
  • Transition between states – if there is a delay between states and its important to convey that state uncertainty
  • Failed to complete some operation – if failure needs to be distinct from the true/false state since false itself isn’t semantically correct

Traditionally, dev’s have just held another state variable to indicate the indeterminate state, and if not indeterminate, then consider the boolean value. This works, but why not carry it through and wrap it up nicely by using this type? The only reason that I can think of for not doing this is that if the indeterminate state covered a set of values, then there is extra overhead associated with having each state variable allowing for the indeterminate state (assuming that the indeterminate covers all state variables equally).

The only gotcha that I found when playing with this so far (on my OSX machine, gotta try GNU/Linux)

boost::tribool t1(boost::indeterminate)
t1 == boost::indeterminate // is FALSE!

You have to use indeterminate(t1) // which returns a bool