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*******@gmai l.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*******@gmai l.com> wrote in message
news:86******** *************** **@posting.goog le.com...

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*******@gmai l.com> wrote in message
news:86******** *************** **@posting.goog le.com...

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_polymo rphic {
private:

class NonVirtual : public T {
public:

~NonVirtual ( void ) {}

};

class Virtual : public T {
public:

virtual ~Virtual ( void ) {}

};

public:

CHECK_is_polymo rphic ( 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_polym orphic<> 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 misunderstandin g 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******@mkwah ler.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*******@gmai l.com> wrote in message
news:86******** *************** **@posting.goog le.com...

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