karl@haddock.ima.isc.com (Karl Heuer) (05/27/90)
In article <4232@castle.ed.ac.uk> aipdc@castle.ed.ac.uk (Paul D. Crowley) writes: >Peeve: why doesn't C have a type "boolean" built in? Answer relative to Classic C: K and R wanted to keep the language small, and decided that the more powerful% type "int" was sufficient. (In fact, there's evidence that at least one of them prefers to use an arithmetic type even in a language that already supports booleans.) Answer relative to ANSI C: because it wasn't within the charter of X3J11 to invent new features without a compelling reason. The idea was to standardize the language, not build a new one. Personal opinion: I'd have been satisfied with a typedef and two macro constants (or enums), hidden in either <stddef.h> or a separate header <bool.h>, with the compiler having the option of strictly enforcing the boolean-only use of this type. >I'm sure there's some compiler somewhere that could use it to >improve executables. There are some improvements that can be made (particularly in register allocation for functions that have more than one boolean variable with auto storage duration), but I think the more important improvement gain is in reducing programmer error by enforcing the restricted rules. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint ________ % int *is* more powerful than boolean, but this doesn't make it a better tool. (cf. the powerful flow control construct "goto".)
cepek@spanky.mgi.com (05/31/90)
In article <4232@castle.ed.ac.uk> aipdc@castle.ed.ac.uk (Paul D. Crowley) writes: >Peeve: why doesn't C have a type "boolean" built in? It seems natural, >and I'm sure there's some compiler somewhere that could use it to >improve executables. Among our "company-common" .H files, the compiler/target-machine dependent one includes the following pseudo-types: #define bool int8 /* smallest entity for TRUE or FALSE */ #define boolean int /* fast/simple entity for TRUE or FALSE */ This allows the programmer to choose between space and speed. "int8" represents the smallest, "reasonable accessable" datum size available for this particular compiler/target-machine. "int" seems the logical choice for boolean here, but perhaps on some machine somewhere a smaller datum would be as easy/faster to use for the simple operations that booleans are involved in. +------------------------------------------------------------------------+ | Michael Cepek "Engage." | | Programmer/Analyst | | Internet: Cepek@MGI.COM | | Management Graphics, Inc. Voice: +1 612/851-6112 | | 1401 East 79th Street Operator: +1 612/854-1220 | | Minneapolis, MN 55425 USA Fax: +1 612/854-6913 | +------------------------------------------------------------------------+
guy@auspex.auspex.com (Guy Harris) (06/01/90)
>There are some improvements that can be made (particularly in register >allocation for functions that have more than one boolean variable with auto >storage duration), And, perhaps, for what it's worth, in choosing representations that fit what some architectures might prefer; e.g., the 68K has an instruction to set a byte based on the condition codes, but the "true" value is all ones, so C compilers have to stuff a "negate" instruction after the "seq" in something like a = (b == c); I tend to doubt the win of avoiding that "neg" instruction would be large, and suspect it would, in most cases, not even be measurable, however.
karl@haddock.ima.isc.com (Karl Heuer) (06/05/90)
In article <20.266429f6@spanky.mgi.com> Cepek@MGI.COM writes: >Among our "company-common" .H files, the compiler/target-machine dependent >one includes the following pseudo-types: >#define bool int8 /* smallest entity for TRUE or FALSE */ >#define boolean int /* fast/simple entity for TRUE or FALSE */ > >This allows the programmer to choose between space and speed. Defining both `bool' and `boolean', with different meanings, is probably a mistake. The very existence of a typedef named `int8' is questionable. (Yes, I know the reason.) And it's probably not worthwhile to have the `small' type, since if you have enough of them that the factor of (probably) 4 is significant, you might as well also go for the factor of (probably) 8 that you get by using packed bit vectors. (The time cost isn't as bad as one often hears, since you don't normally have to go around packing and unpacking the things--the common operations on booleans are test, set, and clear, none of which is hard. The only real pain is that you can't use normal C syntax; you have to go through macros.) Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint Followups to comp.lang.c.