Tribool issue with logical operators && and ||
Hello boost-users I just ran into quite a bad issue with boost::tribool. The overloaded operators && and || may (and normally do) evaluate the righthand side of logical expressions although not needed/permitted. They i.e. evaluate the rhs expression in a conjunction where the first term is false. This leads of course to very surprising results. IMHO, the provided operators should be removed or should honor normal semantics. Shall I issue a bug-report? I think the current situation is quite unconvincingly. Regards James
Hi James, Unfortunately it is not possible to emulating the short-circuiting behavour of the inbuilt && and || operators, as both sides are just arguments to a function disguised as an operator. However I do agree that this behaviour is unexpected to say the least, and terrible for other people looking at the code without knowing they aren't native booleans (and expecting short-circuiting operators). However it is hard to consider an alternative syntax which makes tribools looks anything like native booleans... BTW, this is the very reason why Meyers (in More Effective C++) says to never overload boolean operators! Alex 2008/5/13 Jean-Pierre Bergamin <james@ractive.ch>:
Hello boost-users
I just ran into quite a bad issue with boost::tribool. The overloaded operators && and || may (and normally do) evaluate the righthand side of logical expressions although not needed/permitted. They i.e. evaluate the rhs expression in a conjunction where the first term is false.
This leads of course to very surprising results. IMHO, the provided operators should be removed or should honor normal semantics. Shall I issue a bug-report? I think the current situation is quite unconvincingly.
Regards
James
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Quoting Jean-Pierre Bergamin <james@ractive.ch>:
Hello boost-users
I just ran into quite a bad issue with boost::tribool. The overloaded operators && and || may (and normally do) evaluate the righthand side of logical expressions although not needed/permitted. They i.e. evaluate the rhs expression in a conjunction where the first term is false.
This leads of course to very surprising results. IMHO, the provided operators should be removed or should honor normal semantics. Shall I issue a bug-report? I think the current situation is quite unconvincingly.
Such overloaded operators can't honour "normal" semantics, so that option is out. On the other hand, removing the operators would substantially undermine the whole idea of the tribool class... so I don't think that could be done either. I was surprised though that a "usual" cautionary note about such overloaded operators doesn't appear in the docs though.. perhaps you could add a bug report or patch for that? Pete
Peter Bartlett schrieb:
Quoting Jean-Pierre Bergamin <james@ractive.ch>:
Hello boost-users
I just ran into quite a bad issue with boost::tribool. The overloaded operators && and || may (and normally do) evaluate the righthand side of logical expressions although not needed/permitted. They i.e. evaluate the rhs expression in a conjunction where the first term is false.
This leads of course to very surprising results. IMHO, the provided operators should be removed or should honor normal semantics. Shall I issue a bug-report? I think the current situation is quite unconvincingly.
Such overloaded operators can't honour "normal" semantics, so that option is out. On the other hand, removing the operators would substantially undermine the whole idea of the tribool class... so I don't think that could be done either. I was surprised though that a "usual" cautionary note about such overloaded operators doesn't appear in the docs though.. perhaps you could add a bug report or patch for that?
The real problem lies in the implicit conversion to bool, which does not obviously let you think that an overloaded && operator is used and code like if (p != NULL && p->returnsTribool()) will definitivley be used without hesitation. As you said, there's no way to emulate shortcut evaluation with an overloaded operator && in this case. An option would be to remove the implicit conversion to bool at all. The dereference operator could be (mis)used if conversion to a plain boolean value is needed. The logical operators then could still be overridden for "tribool operator<tribool, tribool>&&" to handle the indeterminate state. Example: boost::tribool result = do_you_use_boost(); if(*result) { cout << "yes" <<endl; } else if (!*result) { cout << "no" <<endl; } else { cout << "don't known" <<endl; } something *p = new something(); if (p && *(p->returnsTribool()) ) { p->someMethod(); } What do you think? Regards James
participants (3)
-
Alex MDC -
Jean-Pierre Bergamin -
Peter Bartlett