|
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