Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!tut.cis.ohio-state.edu!YAHI.STANFORD.EDU!tiemann
From: tiemann@YAHI.STANFORD.EDU (Michael Tiemann)
Newsgroups: gnu.g++.bug
Subject: size of empty classes
Message-ID: <8908141630.AA14115@yahi.Stanford.EDU>
Date: 14 Aug 89 16:30:37 GMT
References: <8908141613.AA23693@dsys.ncsl.nist.gov>
Sender: daemon@tut.cis.ohio-state.edu
Reply-To: tiemann@lurch.stanford.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 83


   Date: Mon, 14 Aug 89 12:13:26 EDT
   From: Root Boy Jim 
   Organization: National Institute of Standards and Technology
	   formerly National Bureau of Standards
   Disclaimer: Opinions expressed are those of the sender
	   and do not reflect NIST policy or agreement.

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

   ? I use g++ 1.35.1- on a Sun3 running OS 3.5.

   Just a bit of speculation here. I hope you don't think all that
   whiz-bang object-oriented stuff comes for free. Most likely those two
   bytes are a pointer into some table telling you what class the thing
   really is. Remember that when deriving one class from another, some
   means of dynamically determining to which class an object belongs
   must be provided. The higher level the language, the farther you
   get from what the thing really is. Live with it.

   ?    Stephane Chatty      chatty@frlri61.bitnet, chatty@lri.lri.fr
   ? LRI, Universite d'Orsay
   ?    Orsay, FRANCE

	   Root Boy Jim
	   Have GNU, Will Travel.

Why speculate when you can have the answers?  Having GNU, we can
travel to the source code and find out:

from cplus-class.c (finish_struct):

  layout_type (t);
  /* C++: do not let empty structures exist.  */
  if (integer_zerop (TYPE_SIZE (t)))
    TYPE_SIZE (t) = TYPE_SIZE (char_type_node);

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.  This means that

	empty *p = new p;

	...

	if (p == 0)
	  /* Ambiguous: maybe it is NULL, maybe it is `allocated'.  */

is highly non-portable.  I asked chatty why zero-sized structures were
desirable.  I have yet to receive an answer.  I do permit zero-sized
arrays, because they are useful when they are the last element in a struct:

	struct vector
	{
	  int len;
	  int elts[0];	/* If len == 0, no need to subtract 1 from size.  */
	};

Again, if a good case can be made for empty structures, I am willing
to be convinced.  But first you must convince me.

>From above:

>   Just a bit of speculation here. I hope you don't think all that
>   whiz-bang object-oriented stuff comes for free.
>   ...
>   The higher level the language, the farther you
>   get from what the thing really is. Live with it.

Jim: Don't assume the compiler is gratuitously stupid.  One of the big
features of C++ is the absense of such baggage, in spite of its higher
level.  When virtual functions are used (which was not the case
above), when used carefully, the overhead is small, and competes very
favorably with the C alternative of using switch statements.

Michael