Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!felix!dhw68k!arcturus!evil
From: evil@arcturus.UUCP (Wade Guthrie)
Newsgroups: comp.lang.c
Subject: Re: Definition of boolean type
Summary: How about backward compatibility
Message-ID: <3645@arcturus>
Date: 9 Feb 89 17:15:33 GMT
References: <10@dbase.UUCP> <9609@smoke.BRL.MIL>
Organization: Rockwell International, Anaheim, CA
Lines: 74

In article <9609@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
> In article <10@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes:
> >But what about a boolean type?

ack phht.  Many people have been programming in C for years and have
gotten quite used to C's handling of boolean (translate: int) stuff 
(I even like it).  More importantly, any change to C to include a
boolean type would make a lot of existing code break.  

> >of several ways to handle booleans (and I've worked on code that used all
> >three):
> >1.	typedef short bool;
> >2.	typedef char bool;
> >3.	typedef enum {FALSE=0, TRUE=1} bool;

Why make a simple idea more complicated?  The only place in the code where
this will make any difference is in the declarations (with, possibly, the
exception of the enum form).  The same thing can be done with commenting:

	int	blah,	/* this variable . . . */
		fred,
		flag,	/* boolean: set if ... */
		. . .
 
> >if (flag) in favor of the self-documentation of the explicit if (flag==TRUE).

You can do that whether the type is 'int' or 'bool'.  That is a matter of
style and is certainly called for in many cases.

> 	if ( too_many )

I usually try to make things look like that -- I find it takes a little
more effort in the variable names, but it makes the code a lot more readable.

#ifdef DIGRESSION_OKAY

	Now, if you want to know about putting effort into making 
	variables understandable. . .You got a graphical object which 
	is made up of a linked list of pieces (such as lines, square 
	panels, etc).  You need a structure for the linked list node 
	and a separate structure for each type of piece.  With this 
	arrangement, you could implement a union of pointers to 
	structures (each member of this union points to a different 
	type of piece).  How about this for readable variable names:

	struct ll_node
	{
		struct ll_node *next_piece;
		union
		{
			struct s_panel	*panel;
			struct s_line	*line;
			. . .
		} is_a;
	} object;

	So that in the code one might see:

	something = object.next_piece->is_a.panel

#endif /* DIGRESSION_OKAY */

> generally I dont think of == or != as Boolean operators.

Me either.
 

Wade Guthrie
evil@arcturus.UUCP
Rockwell International
Anaheim, CA

(Rockwell doesn't necessarily believe / stand by what I'm saying; how could
they when *I* don't even know what I'm talking about???)