Boost logo

Boost :

From: Sylvain Pion (pion_at_[hidden])
Date: 2002-09-04 20:31:00


On Wed, Sep 04, 2002 at 04:47:01PM -0300, Fernando Cacciola wrote:
> > I haven't looked at the library yet

Do you think it's appropriate to send a strong recommendation in this case ?

> Therefore, I strongly recommend that if comparison policies are retained,
> their return type shall not be left user-specified and tribool shall not be
> supported as an option.

I beg to differ.

You have not read carefully my email which shows tribool is not the panacea,
have you ?

Here's another drawback of tribool I just thought about.
If I'm correct, for :

  if (x<y && y<z())

tribool forces the evaluatation of the second condition, whereas bool doesn't.
Even without any indeterminate state whatsoever.

bool has a standard well defined meaning which everybody knows.
Going to tribool changes a lot of things in subtle ways, and I simply
don't think it's only for the better.

For my own application, where I re-use template code (which assumes exact
arithmetic), notifying overlaps by exceptions, I want bool. I don't want a
different logic that changes my program in manners difficult to predict.
Basically that would force me to review all my code to see if there can be a
culprit somewhere (and maintain this thinking for new code).

Moreover, as we want to offer some compatibility with other IA libraries
(and none of them has a 3-state return type, but all of them are useful,
not the result of the dream of a possible fancy application somewhere),
we'd better allow bool and the comparison policies mecanism for flexibility.

I think there are guide lines for C++ beginners in books such as Meyers'
which basically say :
- do not overload operators && and ||.
- do not abuse implicit conversions.

You are advocating both.
Did you _really_ think about the consequences hidden behind the fancy tool ?
I'm not sure.

-- 
Sylvain

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