On 22/01/2010 09:59, bearophile wrote:
Ali:
We've been bitten by the following bug recently in C code: uint
flag = 0x1; uint flags;
if (flags | flag) { dout.writefln("oops"); }
The programmer intended&. It is (almost?) always an error to use |
in a conditional.
Why do you think it's almost always an error?
I have seen more than one time a related bug in C code (once written
by me and other times written by other people): if (foo& bar) {...
instead of: if (foo&& bar) {...
To avoid this kind of bug you can disallow integers in conditionals
(requiring something like a ! or == 0 to turn an integral value in a
boolean) as Java (and partially Pascal), or you can remove the&& ||
from the language and replace them with "and" and "or", so it becomes
easy to tell them apart from bitwise operators. I like the second
way.
Bye, bearophile
Instead of renaming the boolean ops they should simply be removed. The
type system gives you all the required information to know what to do
without needlessly duplicating the syntax:
uint a, b; // init to whatever
bool c, d; // ditto
auto r1 = a AND b; // a & b
auto r2 = c AND d; // c && d
...
AND stands for whatever *single* syntax is chosen for this.
the compiler will implement the boolean version with lazy evaluation and
the unsigned integral versions (uint, ulong, ...) with eager evaluation.
If someone really want to use Boolean ops on numbers [s]he could always
do that explicitly:
cast(bool)myNum AND whatever
