🚀 go-pugleaf

In article <8908141630.AA14115@yahi.Stanford.EDU> tiemann@lurch.stanford.edu writes:
>   > From: chatty%FRLRI61.BITNET@cunyvm.cuny.edu
>   > I just discovered that an empty class has a non-null size. Is that
>   > intentional?  If it is, what are those 2 bytes for?  Until now, I
>   > thought having an empty base class was for free. I am disappointed.
>There is one byte reserved by this action on sparc and VAX, and two
>bytes on m68k and i386.  Why not let empty structures exist?  Well,
>for one thing, different implementations of malloc do different things
>when called with zero for an argument.  Some systems will allocate a
>chunk which gives the user zero size (but a four-byte overhead for
>malloc).  Other systems will just return zero.  
>
>Michael

I hadn't thought of the malloc problem.

The reason I would consider more fundamental is to preserve object identity:
two different objects, whether empty of data or not, should be distinguishable
from one another.  In C++ you determine object identity by its address.
Allocating at least a byte for each object seems the only way to do this.

cfront-1.2 squeezes out (does not allocate) the extra bytes for empty
base classes if the derived class has any variables.  I'm not sure why
this cannot be done with multiple inheritance, but GNU1.35 and AT&T2.0 
both seem to keep the extra bytes.  I'd be curious to find out why.

	// on a sun3:

		struct B { }; 		
		struct D : B { int i; };

		main()   {printf("%d %d\n", sizeof (B), sizeof (D) ); }

	when executed:
			  cfront1.2 prints:  2 4
			  cfront2.0 prints:  2 6
			g++-1.35.1- prints:  2 6

strick
-- 
					strick@osc.com     415-325-2300
					uunet!lll-winken!pacbell!osc!strick
					( also strick@gatech.edu )