Re: size of derived classes - misfeature of gcc?

Re: size of derived classes - misfeature of gcc?

[Mike Stump]

> Date: Mon, 7 May 2001 15:45:11 +0200
> From: Christian Szegedy <szegedy@or.uni-bonn.de>
> To: gcc-help@gcc.gnu.org, gcc@gcc.gnu.org

> I've got a question regarding the size and type management of gcc.
> Suppose that I ompile the follwoing programm using gcc 2.95.2 or
> 2.95.3:

> Then, I would except that C and B have both size 4, and therefore the output
> should be:
> 1 4 4

> The result of this run is:
> 1 8 4 
> for some reason I don't understand.

> Is there some important reason for gcc to behave in this way?

Backwards compatibility is the main reason.

> Are the future versions of gcc going to have this misfeature?

No.  The upcoming gcc 3.0 I think will print 1 4 4 as I recall.

Please don't post to gcc-help and gcc at the same time, thanks.

Hope this helps.  If you'd like more background information, search on
google/dejanews for empty base class optimization, I'm sure lots of
folks have said lots about it already.

Re: size of derived classes - misfeature of gcc?

[Ingo Krabbe]

On Mon, 7 May 2001, Christian Szegedy wrote:

> Hi!
>
> I've got a question regarding the size and type management of gcc.
> Suppose that I ompile the follwoing programm using gcc 2.95.2 or 2.95.3:
>
> -------------------------------------------------------------------------------
>
> #include <stdlib.h>
> #include <stdio.h>
>
> class A
> {
> public:
> };
>
> class B : public A
> {
> public:
>    int i;
> };
>
> class C
> {
> public:
>    int i;
> };
>
>
> void main()
> {
>    printf("%u %u %u\n",(unsigned)sizeof(A),
> 	                    (unsigned)sizeof(B),
>                        (unsigned)sizeof(C));
> }
>
> -------------------------------------------------------------------------------
>
> Then, I would except that C and B have both size 4, and therefore the output
> should be:
> 1 4 4
>
> The result of this run is:
> 1 8 4
> for some reason I don't understand.
>
> Other compilers (e.g. xlC under AIX) produce the expected output above.
> Of course this is no bug, since the generated code runs without errors.
> But it can pose a significant memory overhead in practical cases in which
> A has some static functions and data which is shared by several classes which
> are small, but have a lot of instances (the case I actually have).
>
> Is there some important reason for gcc to behave in this way?
>
> Are the future versions of gcc going to have this misfeature?

I think the reason for this behaviour is highly system dependent !
You can even tune this behaviour sometimes with alignment features
and it may vary by optimization options.
It has to do with alignment. Also the gcc may not honour data structures
without data. Your example is quite esoteric.

CU INGO

Re: size of derived classes - misfeature of gcc?

[Jakub Jelinek]

On Mon, May 07, 2001 at 03:45:11PM +0200, Christian Szegedy wrote:
> Then, I would except that C and B have both size 4, and therefore the output
> should be:
> 1 4 4
> 
> The result of this run is:
> 1 8 4 
> for some reason I don't understand.

In the new g++ ABI this gives 1 4 4.

	Jakub

size of derived classes - misfeature of gcc?

[Christian Szegedy]

Hi!

I've got a question regarding the size and type management of gcc.
Suppose that I ompile the follwoing programm using gcc 2.95.2 or 2.95.3:

-------------------------------------------------------------------------------

#include <stdlib.h>
#include <stdio.h>

class A
{
public:
};

class B : public A
{
public:
   int i;
};

class C
{
public:
   int i;
};


void main()
{
   printf("%u %u %u\n",(unsigned)sizeof(A),
	                    (unsigned)sizeof(B),
                       (unsigned)sizeof(C));
}

-------------------------------------------------------------------------------

Then, I would except that C and B have both size 4, and therefore the output
should be:
1 4 4

The result of this run is:
1 8 4 
for some reason I don't understand.

Other compilers (e.g. xlC under AIX) produce the expected output above.
Of course this is no bug, since the generated code runs without errors.
But it can pose a significant memory overhead in practical cases in which
A has some static functions and data which is shared by several classes which
are small, but have a lot of instances (the case I actually have).

Is there some important reason for gcc to behave in this way?

Are the future versions of gcc going to have this misfeature?