Thread View: gnu.g++.bug
4 messages
4 total messages
Started by Root Boy Jim
Mon, 14 Aug 1989 16:13
size of empty classes
Author: Root Boy Jim
Date: Mon, 14 Aug 1989 16:13
Date: Mon, 14 Aug 1989 16:13
22 lines
1402 bytes
1402 bytes
? 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.
size of empty classes
Author: Michael Tiemann
Date: Mon, 14 Aug 1989 16:30
Date: Mon, 14 Aug 1989 16:30
83 lines
3672 bytes
3672 bytes
Date: Mon, 14 Aug 89 12:13:26 EDT
From: Root Boy Jim <rbj@dsys.ncsl.nist.gov>
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
Re: size of empty classes
Author: mx!cbcscmrs
Date: Fri, 18 Aug 1989 02:03
Date: Fri, 18 Aug 1989 02:03
45 lines
2243 bytes
2243 bytes
In article <8908141613.AA23693@dsys.ncsl.nist.gov> rbj@DSYS.NCSL.NIST.GOV (Root Boy Jim) 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.
>
>? 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.
Well, consider it padding... (On a vax, with 1.35.0 anyway...)
I have a simple class like:
class oXdisplay {
Display *dpy;
dpy() { ... }
~dpy() { ... }
};
And it does the Right Thing. It consumes a whole four bytes of memory per
object. The Display* alone takes four bytes...
But I DID find it interesting that an empty class on my machine did take
a byte; just one. A class with just a char in it also took one byte.
And a class with an int in it took 4 bytes.
Note: due to memory alignments, all classes eat four bytes of memory
apiece.
The code, just if you want to see it is around line 729 of stor-layout.c
in 1.35.0 and looks like:
/* C++: do not let empty structures exist. */
if (const_size == 0 && var_size == 0)
const_size = size_unit;
So g++ does not need or use it, the question to the writers (Michael???)
why force it up to one?
Re: size of empty classes
Author: Doug Schmidt
Date: Fri, 18 Aug 1989 20:44
Date: Fri, 18 Aug 1989 20:44
49 lines
2430 bytes
2430 bytes
In article <2271@csun.edu>, mx!cbcscmrs@csun writes:
>So g++ does not need or use it, the question to the writers (Michael???)
>why force it up to one?
In case you missed this before, here is Michael's answer to this
exact question from about 3 days ago:
----------------------------------------
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.
--
Master Swordsman speak of humility; | schmidt@ics.uci.edu (ARPA)
Philosophers speak of truth; | office: (714) 856-4034
Saints and wisemen speak of the Tao of no doubt;
The moon, sun, and sea speaks for itself. -- Hiroshi Hamada
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads