[comp.lang.c] boolean

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.

kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (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.

All the compilers I've seen for 80x86 (excepting 80[34]86) always allocate
at least one word in the stack frame for variables, even if only one byte
is needed.  I surmised that it was to keep the stack pointer aligned to an
even address, which allows for a small speed improvement on the
8086/80186/80286 (but no speed improvement on 8088/80188.)  Static variables
were allocated less discriminitely, but were suitably aligned as required.

Not having worked with 680x0, so I can't comment reliably on that architecture, 
and I haven't delved into the code generated by the compiler on our SPARCS,
but in both cases, I'd hazard a guess that a similar consideration might come
into play.

So, IMHO, I'd guess that letting the programmer choose between space and
speed would be halfty-fifty at best.  Half a chance at getting it right,
50% chance of getting it wrong.  My rule of thumb has always been: "Make it 
work first, then make it fast."

kaleb@thyme.jpl.nasa.gov            Jet Propeller Labs
Kaleb Keithley

cepek@spanky.mgi.com (06/06/90)

In article <16784@haddock.ima.isc.com>, karl@haddock.ima.isc.com
(Karl Heuer) writes:
> 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.)

I will (have) start(ed) a separate thread for this topic.

>                      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.)

OK, so to summarize the ups and downs of both ways of implementing "bool":
           _int_8_bool_                     _bitfield_bool_
	normal C syntax      versus     using "painful" macros
        quicker              versus     "not too bad" time cost
        less dense           versus     more dense (twice)

The most significant item for me, a programmer using this, is item #1.
The last thing I want to have to cope with is an awkward syntax for doing
something simple.  Also, switching from using a "bool" to using a "boolean"
(or vice versa), is very easy (if rare).  Item 2 is nice, but not significant
(for us).  Item 3 is also not very important in our situation; we appreciate
the extra density beyond "boolean", but maximal density isn't important.

                  - - - - - - - - - - - - - - - - - - - - 

I'm not trying to start a war here.  I've only been using C for 4 years
(programming for 12).  I'm all for learning new methods and discussing
alternative approaches; in fact I enjoy it.

+------------------------------------------------------------------------+
|  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       |
+------------------------------------------------------------------------+

karl@haddock.ima.isc.com (Karl Heuer) (06/11/90)

In article <24.266bdce0@spanky.mgi.com> cepek@spanky.mgi.com writes:
>OK, so to summarize the ups and downs of both ways of implementing "bool":
>           _int_8_bool_                     _bitfield_bool_
>        normal C syntax      versus     using "painful" macros
>        quicker              versus     "not too bad" time cost
>        less dense           versus     more dense (twice)

No, it's 8 times more dense (32 per word instead of 4, in the model I was
using).  And this table ignores the third option of using `int'.  My argument
is that either you have a large array of booleans so that the inconvenience of
the macros is outweighed by the space savings, or else you don't, in which
case there's also probably no advantage to using `char' rather than `int'.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint