HARGED%ti-eg.csnet@CSNET-RELAY.ARPA (05/06/86)
>(2) There isn't any ^^ (XOR) operator either, as in > if(divisor <0) ^^ (dividend <0) > quotient = -quotient; Periodically I encounter conditional expressions in the form ((a && !b) || (!a && b)) For those who remember their Karnaugh maps, that is equivalent to (a ^^ b) I normally grit my teeth and use "^", including a note specifying that the variables involved had *better* always be 1 or 0. >(3) There is no boolean data type. No big gripe; >lots of us say "typedef short bool" in our .h files. When I first started using C, I thought I would miss the boolean type. I'll have to admit that I haven't. With a (very) modest amount of discipline, a BOOLEAN can be typedef'ed, and all else remains the same. >o Multiple flag variables with local scope and no address operator (e.g. > variables declared "register bool") could be packed into a single word. *IF* packing bits is feasible on your host machine. (Whether you like it or not) there are many C implementations that can't afford the overhead of bit packing. >o "++x" and "--x" could be defined as "set" and "clear"; "x++" and "x--" > would then be "test and (set|clear)". This would obviate such things as > "if (!flag) { flag=1; printmsg(); }". I think the same problems with doing that now (on integers of whatever size) would plague the boolean type. The code that would have to generated to avoid giving a boolean variable an undefined value would probably match the size of the code currently generated when the user explicitly controls a flag's value. (x=true) and (x=false) for "set" and "clear" seem more than adequate. However, (~x) for "toggle" would be useful. The lack of an efficient toggle operation on integer BOOLEAN's is sometimes a pain. You are aware that the short-circuit evaluation rules associated with || and && actually make them shorthand forms for (a || b) <==> (a ? 1 : (b != 0)) (a && b) <==> (a ? (b != 0) : 0) which might have something to do with their not being included in the set of operators that can be combined with the assignment operator. Richard Hargrove csnet: harged@ti-eg Texas Instruments, Inc arpa : harged%ti-eg@csnet-relay.arpa ---------------------- ------------------------------------
kwh@bentley.UUCP (KW Heuer) (05/09/86)
In article <559@brl-smoke.ARPA> HARGED%ti-eg.csnet@CSNET-RELAY.ARPA writes: >>o Multiple flag variables with local scope and no address operator (e.g. >> variables declared "register bool") could be packed into a single word. > >*IF* packing bits is feasible on your host machine. (Whether you like it or >not) there are many C implementations that can't afford the overhead of bit >packing. The bits don't need to be explicitly packed and unpacked except to convert between bool and int. Otherwise a bit-test, bit-set, and bit-clear will do, I think; these are just "&", "|", and "&~", and are very common instructions. (Anyway, an implementation is free to NOT pack the bits, just as it can put a char in a 32-bit word if the alternative is too much trouble.) >>o "++x" and "--x" could be defined as "set" and "clear"; "x++" and "x--" >> would then be "test and (set|clear)". This would obviate such things as >> "if (!flag) { flag=1; printmsg(); }". > >I think the same problems with doing that now (on integers of whatever size) >would plague the boolean type. The code that would have to generated to avoid >giving a boolean variable an undefined value would probably match the size >of the code currently generated when the user explicitly controls a flag's >value. Actually, I was introducing "x++" for the user's benefit, not the machine's. I wouldn't mind if it generated the same code as in the explicit case; after all, it's only two instructions (test, followed by store-constant). However, I'd expect a machine with an efficient test-and-set instruction to use it. >However, (~x) for "toggle" would be useful. The lack of an efficient >toggle operation on integer BOOLEAN's is sometimes a pain. I see no reason to change it from "!" to "~". The only case where it's inefficient now is with "x = !x", which could indeed be optimized if "x" is known to be boolean rather than int. (Of course you can write "x ^= 1".) Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint