Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!lth.se!newsuser
From: dag@control.lth.se (Dag Bruck)
Newsgroups: comp.lang.c++
Subject: Re: Boolean confusion (class implementation)
Summary: Writing a class for boolean _is_ a problem
Message-ID: <1991Jun1.214309.15094@lth.se>
Date: 1 Jun 91 21:43:09 GMT
References: <1991May30.060200.6590@lth.se> <998@elan.Elan.COM>
Sender: newsuser@lth.se (LTH network news server)
Distribution: comp.lang.c++
Organization: Department of Automatic Control, Lund, Sweden
Lines: 101

In article <998@elan.Elan.COM> tom@elan.Elan.COM (Thomas Smith) writes:
>From article <1991May30.060200.6590@lth.se>, by dag@control.lth.se (Dag Bruck):
>> I once tried to implement `class boolean' and failed.  Firstly there
>> was a performance problem, which I think good compilers could
>> overcome.  Secondly, I don't think I gained anything in type safety
>> and little in convenience: to be at all useful I needed implicit type
>> conversions int->boolean and boolean->int.
>
>I have successfully implemented Boolean data types in several large
>projects (100K+ lines of C++) at the last two companies I have worked
>for.  If you set it up right, you do get the type-safety without the
>performance penalty.
>
>    class Boolean {
>	unsigned char value;
>    public:
>	Boolean()  {}
>	Boolean(int i) { value = ((i) ? 1 : 0); }
>
>	operator int() const { return (int) value; }
>    };

Tom's approach is very similar to the ones I tried.  Unfortunately, I
disagree with Tom about the usefulness of such a class.  Let's take a
look at this example:

	Boolean g(int x, Boolean y)
	{
	  Boolean z = y;
	  z = x;
	  return z;
	}

I compiled this on a Sun-3 with -O4 optimization.  The assembly code
is enclosed at the end for those who are interested.  The problems I
have is:

1.  Class Boolean occupies two bytes; a minor inconvenience.

2.  Cfront will not accept `register' declarations for `z' which will
    give me a performance hit.

3.  Assignment by an `int' is possible because there is a constructor.

    >Notice that initialization by int is allowed (via constructor),
    >but assignment is not (no operator=(int)).

    Not true.  We can even assign a `char' or `double' to `z',
    although assigning a double will give us a warning.

4.  Returning a class or a struct is awkward, even in this case where
    the compiler could have returned it in a register.

>All in all, though, the good outweighs the bad.

I think we have gained little.  In particular Boolean is not typesafe,
and the `if' statement will still accept any old garbage.

	-- Dag

===========================================================================

Here is a the MC680x0 assembly code produced for the example above.
Configuration was Sun-3, SunOS 4.1.1, Cfront 2.1, Sun's C compiler
with -O4 option.

LL0:
	.data
	.data
	.text
	.proc
|#PROC# 010
	.data
	.lcomm	L2000000,2
	LF16	=	8
	LS16	=	128
	LFF16	=	4
	LSS16	=	0
	LV16	=	4
	.text
	.globl	_g__Fi7Boolean
_g__Fi7Boolean:
|#PROLOGUE# 0
	link	a6,#-8
|#PROLOGUE# 1
	movw	a6@(14),a6@(-2)
	tstl	a6@(8)
	jeq	L77003
	moveq	#1,d1
	jra	L77004
L77003:
	moveq	#0,d1
L77004:
	movb	d1,a6@(-2)
	movl	#L2000000,a1
	movw	a6@(-2),a1@
	movl	a1,d0
|#PROLOGUE# 2
	unlk	a6
|#PROLOGUE# 3
	rts