size of object

[Tarundeep]

hi,

let us say it is a 32 bit processor then the size of the pointer is 32
bits.

now i want to know what would be the size of the class with vtable
pointer in it , that is it has few virtual functions.

Since the very first location of the object memory points to the
vtbale hence that should be 32 bit.

Am i right ??

Pls remove the confusion in my mind.

Also what is the size of the class with no data member and just one
function.

Regards
Tarun

[Sharad Kala]

"Tarundeep" <ta*******@gmail.com> wrote in message > hi,

let us say it is a 32 bit processor then the size of the pointer is 32
bits.

now i want to know what would be the size of the class with vtable
pointer in it , that is it has few virtual functions.
First of all things we are talking about are implementation specific.
Generally a class would not hold a vtable pointer but each object of class
would hold it.
Since the very first location of the object memory points to the
vtbale hence that should be 32 bit.

Am i right ??
No, there is no such promise about v-tables or memory layout made by the
Standard. An implementation _could_ choose to have it the way you are
saying.
Pls remove the confusion in my mind.

Also what is the size of the class with no data member and just one
function.

All that the standard ensures is that if it is the most derived class in a
hierarchy then it will have a size greater than zero. EBCO (Empty base class
optimization) can come into picture with empty base classes.

Sharad

[Mike Wahler]

"Tarundeep" <ta*******@gmail.com> wrote in message
news:86*************************@posting.google.co m...

hi,

let us say it is a 32 bit processor then the size of the pointer is 32
bits.
The size of a pointer on a 32-bit processor might or
might not be 32 bits.

now i want to know what would be the size of the class with vtable
pointer in it ,
that is it has few virtual functions.
The following uses the C++ notion of 'size', as reported
by 'sizeof', that is, measured in bytes.

The size of an object of class type is not affected by how
many member functions the class has, virtual or not.

The size of an object of class type will be at least the
sum of the sizes of its data members (but possibly larger,
since padding is allowed between members); or lacking any
data members, greater than zero.

Since the very first location of the object memory points to the
vtbale hence that should be 32 bit.
The address of an object of class type will be the same address
as that of its first declared data member, if one is declared.
'vtable' is not part of the language, it's a mechanism some
implementations use to achieve polymorphism.

Am i right ??
Nope. :-)

Pls remove the confusion in my mind.

Also what is the size of the class with no data member and just one
function.

The existence or number of member functions does not affect the
size of an object of class type. The size of an object of
class type which has no data members will be greater than zero
(exact size left up to the implementation).

Summary: The actual physical implementation of an object (such
as one of a polymorphic type) might consume more storage than
that reported by 'sizeof'. This extra 'overhead' is not considered
part of the object's size or representation, nor part of the application's
address space.

-Mike

[Kai-Uwe Bux]

Mike Wahler wrote:

"Tarundeep" <ta*******@gmail.com> wrote in message
news:86*************************@posting.google.co m...

hi,

let us say it is a 32 bit processor then the size of the pointer is 32
bits.
The size of a pointer on a 32-bit processor might or
might not be 32 bits.

now i want to know what would be the size of the class with vtable
pointer in it ,
that is it has few virtual functions.

The following uses the C++ notion of 'size', as reported
by 'sizeof', that is, measured in bytes.

The size of an object of class type is not affected by how
many member functions the class has, virtual or not.

Actually, the OP might be not that far off. In many implementations
(especially vtable based ones), the sizeof(T) for a class is affected by
the presence of virtual functions more or less in the way the OP assumes.
The following non-portable trick to do a compile time check for polymorphic
classes relies on it:

template < unsigned long M, unsigned long N >
class CHECK_is_equal {
private:

template < unsigned long A >
class XXX {
public:

void operator== ( const XXX & ) const {};

};

public:

CHECK_is_equal ( void ) {
XXX< M > a;
XXX< N > b;
a == b;
}
};

template < typename T >
class CHECK_is_polymorphic {
private:

class NonVirtual : public T {
public:

~NonVirtual ( void ) {}

};

class Virtual : public T {
public:

virtual ~Virtual ( void ) {}

};

public:

CHECK_is_polymorphic ( void ) {
CHECK_is_equal< sizeof( NonVirtual ), sizeof( Virtual ) > x;
}
};

This works because the vtable pointer consumes some space in the object. As
far as I know, boost::is_polymorphic<> uses a refinement of this idea. I
agree, however, that it is by no means guaranteed by the standard.

The size of an object of class type will be at least the
sum of the sizes of its data members (but possibly larger,
since padding is allowed between members); or lacking any
data members, greater than zero.

Since the very first location of the object memory points to the
vtbale hence that should be 32 bit.

The address of an object of class type will be the same address
as that of its first declared data member, if one is declared.
'vtable' is not part of the language, it's a mechanism some
implementations use to achieve polymorphism.

Am i right ??

Nope. :-)

Pls remove the confusion in my mind.

Also what is the size of the class with no data member and just one
function.

The existence or number of member functions does not affect the
size of an object of class type. The size of an object of
class type which has no data members will be greater than zero
(exact size left up to the implementation).

Summary: The actual physical implementation of an object (such
as one of a polymorphic type) might consume more storage than
that reported by 'sizeof'. This extra 'overhead' is not considered
part of the object's size or representation, nor part of the application's
address space.

I doubt that objects of class T are allowed to use more memory than

malloc( sizeof(T) );

allocates. However, there could be a misunderstanding on my part, because I
am not really clear about what you mean by "overhead" that "is not
considered part of the object's size or representation, nor part of the
application's address space". As far as I can tell, everything that the
compiler needs to stick into an object to make it work as prescribed by the
standard is part of its representation, although the standard makes no
claims as to what those tings might be that compiler sticks in there.
However, if a compiler finds it convenient to stick in a vtable pointer,
then I do not see any language in the standard that would sizeof() prevent
from accounting for that pointer. (Then, again, the standard is long; and I
might be missing something.)
Best

Kai-Uwe Bux

[JKop]

Tarundeep posted:

hi,

let us say it is a 32 bit processor then the size of the pointer is 32
bits.
A very fair assumption.
now i want to know what would be the size of the class with vtable
pointer in it , that is it has few virtual functions.

Since the very first location of the object memory points to the
vtbale hence that should be 32 bit.
No necessarily the very first part of the object, but again to assume so
would be a fair assumption.
Am i right ??

Pls remove the confusion in my mind.

Also what is the size of the class with no data member and just one
function.
If the function is NON-virtual, then an object of the class shouldn't
consume ANY memory. (But again, a perverted implementation may choose to do
whatever it likes!).

If the function is virtual, then an object of the class should theoretically
be of the size: sizeof(void*), ie. the size of a pointer (to the vtable).
But again, it's all implementation specific...

Note, even if you declare the function as virtual, if the compiler can
figure out at compile time what function you want to call, it may optimize
away the vtable, leaving you with objects which take up no memory.

There's some rule somewhere I believe that sizeof(ANYTHING) >= 1 in C++, but
still this doesn't mean that objects of the class will actually allocate any
memory.
-JKop

Regards
Tarun

Yeah, that makes perfect sense.

[Sharad Kala]

"JKop" <NU**@NULL.NULL> wrote in message > Tarundeep posted:

If the function is NON-virtual, then an object of the class shouldn't
consume ANY memory. (But again, a perverted implementation may choose to do whatever it likes!).
There is valid reason why implementations reserve some memory for objects of
empty classes. Think about array of such a class and addresses of elements
in it.
There's some rule somewhere I believe that sizeof(ANYTHING) >= 1 in C++, but still this doesn't mean that objects of the class will actually allocate any memory.

Well, let's get what the Standard says (5.3.3/2)- "The size of a most
derived class shall be greater than zero". The reason for "most derived" is
that an implementation could implement EBCO.

Sharad

[Tom Widmer]

On Tue, 14 Sep 2004 05:21:02 GMT, "Mike Wahler"
<mk******@mkwahler.net> wrote:

Since the very first location of the object memory points to the
vtbale hence that should be 32 bit.

The address of an object of class type will be the same address
as that of its first declared data member, if one is declared.

That is true only for POD types, and may or may not be true for
non-PODs. On most implementations it isn't true for objects with
virtual functions.

Tom

[Andrew Koenig]

"Tarundeep" <ta*******@gmail.com> wrote in message
news:86*************************@posting.google.co m...

let us say it is a 32 bit processor then the size of the pointer is 32
bits.

now i want to know what would be the size of the class with vtable
pointer in it , that is it has few virtual functions.
The typical implementation will add one word to the contest of the object
for a vtable pointer, plus any padding that might be necessary for alignment
purposes. The real question, though, is why do you care?
Since the very first location of the object memory points to the
vtbale hence that should be 32 bit.
There is no reason to believe that the vtable pointer will always be at the
beginning of the object.
Also what is the size of the class with no data member and just one
function.

For most implementations, the size of an object is the size of its data
members, plus one word for the vtable, plus one word for the vtable of every
base class (direct or indirect) that has virtual functions, plus padding.

But I still want to know why you care.

[JKop]

> For most implementations, the size of an object is the
size of its data

members, plus one word for the vtable, plus one word for the vtable of every base class (direct or indirect) that has virtual functions, plus padding.
"plus one word for the vtable of every base class..."

BULLSHIT.

But I still want to know why you care.

It's called curiousity and wanting to know what goes on
under the hood. What's with the arogant attitude, is it
because you're an asshole?
-JKop

[Mike Wahler]

"JKop" <NU**@NULL.NULL> wrote in message
news:wP******************@news.indigo.ie...

For most implementations, the size of an object is the

size of its data

members, plus one word for the vtable, plus one word for

the vtable of

every base class (direct or indirect) that has virtual

functions, plus

padding.

"plus one word for the vtable of every base class..."

BULLSHIT.

But I still want to know why you care.

It's called curiousity and wanting to know what goes on
under the hood. What's with the arogant attitude, is it
because you're an asshole?

Good job. You've just insulted a person who is more
capable of helping you with C++ than well over 99 percent
of everyone posting here.

If you have issues with the correctness of someone's
assertions, then provide rational refutation.

Expletives and name calling are the traits of an
immature child, produce nothing of value, and are
not appreciated here.

-Mike

[Karl Heinz Buchegger]

JKop wrote:

For most implementations, the size of an object is the

size of its data

members, plus one word for the vtable, plus one word for

the vtable of

every base class (direct or indirect) that has virtual

functions, plus

padding.

"plus one word for the vtable of every base class..."

BULLSHIT.

But I still want to know why you care.

It's called curiousity and wanting to know what goes on
under the hood. What's with the arogant attitude, is it
because you're an asshole?

I don't think that Andrew is an asshole.

What's wrong with you JKop?
When you joined that group you behaved the same as you
do now. This continued until you realized how less you
know about the things you are talking about and the group
constantly cought you on errors. Then you became a nice
guy and it was a pleasure to read your posts. Now you
fall back to the very same odd behaviour.

If you want to know what your compiler does under the
hood, then by all means request an assembler listing
from your compiler and analyze it. Just as we all
do if we want to know what is going on under the hood.

--
Karl Heinz Buchegger
kb******@gascad.at

[Howard]

"JKop" <NU**@NULL.NULL> wrote in message
news:wP******************@news.indigo.ie...

For most implementations, the size of an object is the size of its data

members, plus one word for the vtable, plus one word for

the vtable of

every base class (direct or indirect) that has virtual

functions, plus

padding.

"plus one word for the vtable of every base class..."

BULLSHIT.

Not a very good refutation there. Care to give me the location of this
statement in the standard? :-)

But I still want to know why you care.

It's called curiousity and wanting to know what goes on
under the hood. What's with the arogant attitude, is it
because you're an asshole?

I would venture to say that it's likely *not* just curiosity. It's quite
possible the OP wants to write specific code that relies on this
information, and doing so will obviously cause problems. Asking *why* a
question is being posed often reveals a basic flaw in assumptions, and
catching that error early on prevents problems for the OP in the future.
(It's also a very good teaching technique, forcing the student to evaluate
their own assumptions and not just spoon-feed them information. It helps
them really *learn*, not just memorize.)

-Howard

[JKop]

JKop posted:

For most implementations, the size of an object is the size of its data members, plus one word for the vtable, plus one word for the vtable of every base class (direct or indirect) that has virtual functions, plus padding.

"plus one word for the vtable of every base class..."

BULLSHIT.

But I still want to know why you care.

It's called curiousity and wanting to know what goes on
under the hood. What's with the arogant attitude, is it
because you're an asshole?
-JKop

Am I the only one that thought Andrew's post was hostile
and confrontational? Here's a few select quotes:

"The real question, though, is why do you care?"

"But I still want to know why you care."

If it were a genuine question, it should have been worded
something along the following lines:

"I'm curious though - why is it that you want to know
this?"

"Again, why do you want to know this?"
As for it being obvious that the OP was more than curious
and was actually going to write a (non-portable) program
which made use of this information, well... I for one can
say that I've asked dozens of questions out of pure
curiosity and I'm glad that I know that information now.

As for some-one being an expert at C++. Give me a break! I
could understand if this was physics or something, where
people are constantly discovering new things, but C++, it's
just a man-made language. Some-one sat down one day and
said:

Okay when you write

int k;

That's going to allocate memory to store an integer.

I've read TCPPL and I can assert that I know C++. Sure,
I've made loads of mistakes in the past, but now Setpember
the 14th, I know C++ and that's because I asked questions
out of curiosty and read a good book that defined the
language.

-JKop

[Richard Herring]

In message <Ae******************@news.indigo.ie>, JKop <NU**@NULL.NULL>
writes

JKop posted:

For most implementations, the size of an object is thesize of its data members, plus one word for the vtable, plus oneword for the vtable of every base class (direct or indirect) that hasvirtual functions, plus padding.
"plus one word for the vtable of every base class..."

BULLSHIT.

But I still want to know why you care.

It's called curiousity and wanting to know what goes on
under the hood. What's with the arogant attitude, is it
because you're an asshole?

Am I the only one that thought Andrew's post was hostile
and confrontational?

It certainly looks that way.

In case you've forgotten, you also appeared to disagree rather
forcefully with his statement about the size of objects. I haven't yet
seen you post anything in support of your position.
Here's a few select quotes:

"The real question, though, is why do you care?"

"But I still want to know why you care."

If it were a genuine question, it should have been worded
something along the following lines:

"I'm curious though - why is it that you want to know
this?"

"Again, why do you want to know this?"
Impressive. Not only do you know C++, but you're an authority on English
writing style.
As for it being obvious that the OP was more than curious
and was actually going to write a (non-portable) program
which made use of this information, well... I for one can
say that I've asked dozens of questions out of pure
curiosity and I'm glad that I know that information now.

As for some-one being an expert at C++. Give me a break! I
could understand if this was physics or something, where
people are constantly discovering new things, but C++, it's
just a man-made language. Some-one sat down one day and
said:

Okay when you write

int k;

That's going to allocate memory to store an integer.

I've read TCPPL and I can assert that I know C++. Sure,
I've made loads of mistakes in the past, but now Setpember
the 14th, I know C++
And you're not a bit arrogant.
and that's because I asked questions
out of curiosty and read a good book that defined the
language.

--
Richard Herring

[Default User]

JKop wrote:

But I still want to know why you care.

It's called curiousity and wanting to know what goes on
under the hood. What's with the arogant attitude, is it
because you're an asshole?

What the hell is the matter with you? Andrew Koenig, besides being
extremely knowledgable on the subject (witness how well-considered the
book he co-authored is considered), is generally helpful and
considerate on the newsgroup.

I had serious questions about why the OP is asking this as well. Often
when people ask about implementation details, it means they are getting
ready to do ill-considered, non-portable things that they should not.

Asking why is a GOOD idea.

Brian Rodenborn

[Sharad Kala]

"JKop" <NU**@NULL.NULL> wrote in message

For most implementations, the size of an object is the

size of its data

members, plus one word for the vtable, plus one word for

the vtable of

every base class (direct or indirect) that has virtual

functions, plus

padding.

"plus one word for the vtable of every base class..."

BULLSHIT.

But I still want to know why you care.

It's called curiousity and wanting to know what goes on
under the hood. What's with the arogant attitude, is it
because you're an asshole?

Too bad...
I really think that we should be careful about the words we use on c.l.c++.
Especially if we want Gurus like Mr. Koenig to share knowledge with all of
us.

Sharad

[E. Robert Tisdale]

Tarundeep wrote:

Let us say it is a 32 bit processor
then the size of the pointer is 32 bits.
Assuming that the machines natural 32 bit data path
is used to represent pointers and do pointer arithmetic, yes.
Now I want to know what would be the size of the class
with vtable pointer in it, that is, it has few virtual functions.
You are confusing class with object.
The class contains the *vtable*.
An onject contains a *pointer* to that vtable.
Since the very first location of the object memory points to the
vtable, hence that should be 32 bit.

Am I right?

Please remove the confusion in my mind.

Also what is the size of the class
with no data member and just one function. cat main.cc #include <iostream>

class Z {
private:
// representation
int I[2];
public:
// functions
friend
std::ostream& operator<<(std::ostream& os, const Z& z);
};

inline
std::ostream& operator<<(std::ostream& os, const Z& z) {
return os << z.I[0] << ' ' << z.I[1];
}

class Y {
private:
// representation
int I;
public:
// constructors
Y(int i = 0): I(i) { }
virtual
~Y(void) { }
};

class X {
private:
// representation
int I;
public:
// constructors
X(int i = 0): I(i) { }
~X(void) { }
};

int main(int argc, char* argv[]) {
const
Y y(13);
std::cout << (const Z&)y
<< " = (const Z&)y" << std::endl;
std::cout << sizeof(y)
<< " = sizeof(y)" << std::endl;
std::cout << sizeof(X)
<< " = sizeof(X)" << std::endl;
return 0;
}
g++ -Wall -ansi -pedantic -o main main.cc
./main

134515856 13 = (const Z&)y
8 = sizeof(y)
4 = sizeof(X)

[Niklas Borson]

JKop <NU**@NULL.NULL> wrote in message news:<wP******************@news.indigo.ie>...

For most implementations, the size of an object is the

size of its data

members, plus one word for the vtable, plus one word for

the vtable of

every base class (direct or indirect) that has virtual

functions, plus

padding.

"plus one word for the vtable of every base class..."

BULLSHIT.

Andrew Koenig might choose not to dignify your rude and
unsubstantiated assertion with a reply, but for the sake of
discussion, let's pretend you had instead asked a polite
question like,

"Really? Why would an object need to contain multiple
vtable pointers?"

Suppose you have a derived class C with two bases A and B, as
follows:

class A {
int data;
public:
virtual ~A() {}
};

class B {
int data;
public:
virtual ~B() {}
};

class C : public A, public B
{
};

Now let's say we have some code like this:

A* a = new A;
delete a;

How does the delete statement work? Typically, the code at
the call site expects the object at the address specified by
'a' to have a certain memory layout, including a vtable
pointer which it can use to invoke the virtual destructor.
Now what if we write the following instead?

A* a = new C;
delete a;

Let's assume the compiler can't figure out the dynamic type of
*a through static analysis. It needs to be able to treat the
variable 'a' as if it pointed to an actual 'A' object. Thus,
'a' needs to contain the address of something with the same
memory layout as an actual 'A' object including the vtable
pointer (so the destructor can be invoked virtually).

Now if instead we write:

B* b = new C;
delete b;

Now the code at the call site can assume that 'b' is the address
of an actual 'B' object, i.e., something with the memory layout
expected of a 'B' object including the vtable pointer. In other
words, it points to the B subobject of the 'C' object. Since C
contains two sobobjects, each with its own vtable pointer,
it follows that each instance of 'C' has two vtable pointers.

This can be easily confirmed:

int main()
{
C c;
printf(
"sizeof(C)==%d &c==%p\n"
"sizeof(A)==%d (A*)&c==%p\n"
"sizeof(B)==%d (B*)&c==%p\n\n",
(int)sizeof(C), &c,
(int)sizeof(A), (A*)&c,
(int)sizeof(B), (B*)&c);
return 0;
}

Output (actually addresses may change, obviously):

sizeof(C)==16 &c==0012FF68
sizeof(A)==8 (A*)&c==0012FF68
sizeof(B)==8 (B*)&c==0012FF70

If C had only one vtable pointer you would expect its size
to be 12 (this being a 32-bit system).

Disclaimer: we're talking about typical implementations here,
not behavior specifically dictated by the standard.

--Nick

[JKop]

Where multiple inheritence is involved, yes you're correct.
-JKop