|[11 earlier articles]|
|Re: Overloaded logic operators firstname.lastname@example.org (Bartc) (2008-11-25)|
|Re: Overloaded logic operators email@example.com (Chris Dodd) (2008-11-25)|
|Re: Overloaded logic operators firstname.lastname@example.org (2008-11-26)|
|Re: Overloaded logic operators email@example.com (Frank Swarbrick) (2008-11-27)|
|Re: Overloaded logic operators firstname.lastname@example.org (Tony Finch) (2008-12-01)|
|Re: Overloaded logic operators alexc@TheWorld.com (Alex Colvin) (2008-12-03)|
|Re: Overloaded logic operators email@example.com (Hans Aberg) (2008-12-04)|
|From:||Hans Aberg <firstname.lastname@example.org>|
|Date:||Thu, 04 Dec 2008 20:44:52 +0100|
|Organization:||Aioe.org NNTP Server|
|Posted-Date:||04 Dec 2008 15:07:11 EST|
Mike Austin wrote:
> In many languages, logic operators "and" and "or" have been overloaded to
> handle more than booleans.
> I'm torn between this being easier for the programmer, or just bad
> practice in general.
It is not the operator overloading that is causing problems, but
implicit type conversions, especially in the case where it loses some
information. The problem is that the effects of such syntax is hard to
detect when debugging.
So, for example, converting (multiprecision) integers to rational
numbers is safe, but converting rational numbers to floats might cause
some unexpected things: unequal numbers may be treated as equal, for
example. Converting floating point numbers implicitly to integers is
bad, because such conversions may need some guards against round-off
> benefit outweigh the effect of overloaded logic?
One such example is C, where it was problematic in C++, wanting to keep
the C syntax.
Return to the
Search the comp.compilers archives again.