C++ Object model layout
 

The C++ Object Model book says that
'Nonstatic data members are allocated directly within each class
object. Static data members are stored outside the individual class
object. Static and nonstatic function members are also hoisted outside
the class object. Virtual functions are supported in two steps:

A table of pointers to virtual functions is generated for each class
(this is called the virtual table).

A single pointer to the associated virtual table is inserted within
each class object (traditionally, this has been called the vptr). The
setting, resetting, and not setting of the vptr is handled
automatically through code generated within each class constructor,
destructor, and copy assignment operator (this is discussed in Chapter
5). The type_info object associated with each class in support of
runtime type identification (RTTI) is also addressed within the
virtual table, usually within the table's first slot.'

Here I understand that one have some means to access:
- non-static data members and
- virtual function of the class object.

But then how one can access the other entities like:
- static data member
- static and non-static member functions?

How the above entities are represented with respect to class object
layout?

Re: C++ Object model layout
 

sumsin wrote:

> The C++ Object Model book says that
> 'Nonstatic data members are allocated directly within each class
> object. Static data members are stored outside the individual class
> object. Static and nonstatic function members are also hoisted outside
> the class object. Virtual functions are supported in two steps:
>
> A table of pointers to virtual functions is generated for each class
> (this is called the virtual table).
>
> A single pointer to the associated virtual table is inserted within
> each class object (traditionally, this has been called the vptr). The
> setting, resetting, and not setting of the vptr is handled
> automatically through code generated within each class constructor,
> destructor, and copy assignment operator (this is discussed in Chapter
> 5). The type_info object associated with each class in support of
> runtime type identification (RTTI) is also addressed within the
> virtual table, usually within the table's first slot.'

That's a way to do it. I don't think the standard is that specific about how
to implement it. But it is a common aproach yes.

> Here I understand that one have some means to access:
> - non-static data members and
> - virtual function of the class object.
>
> But then how one can access the other entities like:
> - static data member
> - static and non-static member functions?

Answer this question: how one can access global variables or namespace scope
functions (in C or C++)?

When you answer that you can apply it to your original questions if you
imagine that static data member are just some global variables with
a "special name" (ie struct A { static int a; }; defines a "global" A::a),
static member functions are the same (ie struct A { static void func()
{} }; defines a "global" A::func()) and non static member functions are
similar to static functions only that they have a hidden "this" parameter,
so struct A { void func() {} }; is basically like having struct A { static
void func(A* this) {} };

> How the above entities are represented with respect to class object
> layout?

They don't have much in common with the object layout.

--
Dizzy

Re: C++ Object model layout
 

In article <4af52a26-03b6-48f2-b348-82edf5490ba7
@v1g2000pra.googlegroups.com>, sumsin123@gmail.com says...

[ ... ]

> But then how one can access the other entities like:
> - static data member

A static data member is just a global variable with a funny name. It's
just assigned an address by the linker, and everything that refers to it
uses that address.

> - static and non-static member functions?

Static member functions are just normal global functions with funny
names -- you might have:

class my_class {
public:
static_func() {}
};

and the compiler turns that into a name like:

static_func$my_class$$void

but past the funny name, it's a rather ordinary global function.

A non-static member function is pretty much the same except that the
compiler generates a bit of extra code so that the function receives a
pointer to the object on which it's being invoked (what's referred to as
'this' in the source code). This is sufficiently common that some
compilers do things like reserving a register specifically for holding
'this'.

> How the above entities are represented with respect to class object
> layout?

They're all just globals with funny names, so there's essentially no
relationship between them and the class layout at all.

Of course, I'm only talking about the typical implementation -- in
theory, all of this _could_ undoubtedly be done in other ways.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Re: C++ Object model layout
 

On Jun 11, 8:09 pm, Jerry Coffin <jcof...@taeus.com> wrote:
> In article <4af52a26-03b6-48f2-b348-82edf5490ba7
> @v1g2000pra.googlegroups.com>, sumsin...@gmail.com says...
>
> [ ... ]
>
> > But then how one can access the other entities like:
> > - static data member
>
> A static data member is just a global variable with a funny name. It's
> just assigned an address by the linker, and everything that refers to it
> uses that address.
>
> > - static and non-static member functions?
>
> Static member functions are just normal global functions with funny
> names -- you might have:
>
> class my_class {
> public:
> static_func() {}
>
> };
>
> and the compiler turns that into a name like:
>
> static_func$my_class$$void
>
> but past the funny name, it's a rather ordinary global function.
>
> A non-static member function is pretty much the same except that the
> compiler generates a bit of extra code so that the function receives a
> pointer to the object on which it's being invoked (what's referred to as
> 'this' in the source code). This is sufficiently common that some
> compilers do things like reserving a register specifically for holding
> 'this'.
>
> > How the above entities are represented with respect to class object
> > layout?
>
> They're all just globals with funny names, so there's essentially no
> relationship between them and the class layout at all.
>
> Of course, I'm only talking about the typical implementation -- in
> theory, all of this _could_ undoubtedly be done in other ways.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.

You mean static data members are just like global variable and non-
static and static member functions are just like normal function. So
these entities do not have any concern with the class object. Is it?

Re: C++ Object model layout
 

sumsin wrote:

> You mean static data members are just like global variable and non-
> static and static member functions are just like normal function. So
> these entities do not have any concern with the class object. Is it?

Exactly. This way it will help you later to understand how pointer to
members (especially to member functions) work. Many people don't understand
these basic things you asked about and thus they come asking why giving a
member function pointer value where a function pointer is expected does not
work.

You can play doing this, struct A {}; Print its sizeof(). Then add a static
function. Print again its sizeof. Then add a member function and print
again the sizeof(). Then add a static data member and print the sizeof.

--
Dizzy

Re: C++ Object model layout
 

On Jun 11, 8:45 pm, dizzy <di...@roedu.net> wrote:
> sumsin wrote:
> > You mean static data members are just like global variable and non-
> > static and static member functions are just like normal function. So
> > these entities do not have any concern with the class object. Is it?
>
> Exactly. This way it will help you later to understand how pointer to
> members (especially to member functions) work. Many people don't understand
> these basic things you asked about and thus they come asking why giving a
> member function pointer value where a function pointer is expected does not
> work.
>
> You can play doing this, struct A {}; Print its sizeof(). Then add a static
> function. Print again its sizeof. Then add a member function and print
> again the sizeof(). Then add a static data member and print the sizeof.
>
> --
> Dizzy

Great! I really enjoyed the play. Also when I add a virtual function
the size increases by 4 byte and that because 'vptr' right!

Re: C++ Object model layout
 

On Jun 11, 8:09 pm, Jerry Coffin <jcof...@taeus.com> wrote:
> In article <4af52a26-03b6-48f2-b348-82edf5490ba7
> @v1g2000pra.googlegroups.com>, sumsin...@gmail.com says...
>
> [ ... ]
>
> > But then how one can access the other entities like:
> > - static data member
>
> A static data member is just a global variable with a funny name. It's
> just assigned an address by the linker, and everything that refers to it
> uses that address.
>
> > - static and non-static member functions?
>
> Static member functions are just normal global functions with funny
> names -- you might have:
>
> class my_class {
> public:
> static_func() {}
>
> };
>
> and the compiler turns that into a name like:
>
> static_func$my_class$$void
>
> but past the funny name, it's a rather ordinary global function.
>
> A non-static member function is pretty much the same except that the
> compiler generates a bit of extra code so that the function receives a
> pointer to the object on which it's being invoked (what's referred to as
> 'this' in the source code). This is sufficiently common that some
> compilers do things like reserving a register specifically for holding
> 'this'.
>
> > How the above entities are represented with respect to class object
> > layout?
>
> They're all just globals with funny names, so there's essentially no
> relationship between them and the class layout at all.

So how they are maintained?
I think compiler create a list with these funny names and linker
assign their corresponding addresses, when ever anybody approach any
funny name that is dereference to the corresponding memory address,
right?

>
> Of course, I'm only talking about the typical implementation -- in
> theory, all of this _could_ undoubtedly be done in other ways.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.

Re: C++ Object model layout
 

In article <8a1ec585-3d56-44cf-9b41-1dfb9558e848
@c19g2000prf.googlegroups.com>, sumsin123@gmail.com says...

[ ... ]

> So how they are maintained?
> I think compiler create a list with these funny names and linker
> assign their corresponding addresses, when ever anybody approach any
> funny name that is dereference to the corresponding memory address,
> right?

Yes, that's pretty much correct. Of course, there can be some exceptions
-- for example, one of the reasons separate compilation of templates is
so difficult to implement is that you can instantiate a template over a
new type. The meaning of code in the template may change, depending on
the type over which it's instantiated, so instantiating over a new type
can mean the template needs to be re-compiled completely, generating
completely different code.

Since the exported template was compiled separately, however, this
requirement for recompilation isn't visible until link time. The linker
checks whether the object file for the template contains code for the
type(s) over which that template is instantiated, and forces it to be
compiled over the new types if needed. After that the link proceeds as
normal.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Re: C++ Object model layout
 

On Jun 11, 5:32 pm, sumsin <sumsin...@gmail.com> wrote:
> On Jun 11, 8:09 pm, Jerry Coffin <jcof...@taeus.com> wrote:
> > In article <4af52a26-03b6-48f2-b348-82edf5490ba7
> > @v1g2000pra.googlegroups.com>, sumsin...@gmail.com says...

> > [ ... ]

> > > But then how one can access the other entities like:
> > > - static data member

> > A static data member is just a global variable with a funny
> > name. It's just assigned an address by the linker, and
> > everything that refers to it uses that address.

> > > - static and non-static member functions?

> > Static member functions are just normal global functions
> > with funny names -- you might have:

> > class my_class {
> > public:
> > static_func() {}
> > };

> > and the compiler turns that into a name like:

> > static_func$my_class$$void

> > but past the funny name, it's a rather ordinary global
> > function.

> > A non-static member function is pretty much the same except
> > that the compiler generates a bit of extra code so that the
> > function receives a pointer to the object on which it's
> > being invoked (what's referred to as 'this' in the source
> > code). This is sufficiently common that some compilers do
> > things like reserving a register specifically for holding
> > 'this'.

> > > How the above entities are represented with respect to
> > > class object layout?

> > They're all just globals with funny names, so there's
> > essentially no relationship between them and the class
> > layout at all.

> > Of course, I'm only talking about the typical implementation
> > -- in theory, all of this _could_ undoubtedly be done in
> > other ways.

I was waiting for that disclaimer:-). (It's another difference
between theory and practice: in theory, it could be done in
another way; in practice, it's not.)

> You mean static data members are just like global variable and
> non- static and static member functions are just like normal
> function. So these entities do not have any concern with the
> class object. Is it?

With regards to generated code, yes. Static members are still
members, however, and things like access control are applied.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Re: C++ Object model layout
 

On Jun 11, 10:14*am, sumsin <sumsin...@gmail.com> wrote:
> The C++ Object Model book says that
> 'Nonstatic data members are allocated directly within each class
> object. Static data members are stored outside the individual class
> object. Static and nonstatic function members are also hoisted outside
> the class object. Virtual functions are supported in two steps:
>
> A table of pointers to virtual functions is generated for each class
> (this is called the virtual table).
>
> A single pointer to the associated virtual table is inserted within
> each class object (traditionally, this has been called the vptr). The
> setting, resetting, and not setting of the vptr is handled
> automatically through code generated within each class constructor,
> destructor, and copy assignment operator (this is discussed in Chapter
> 5). The type_info object associated with each class in support of
> runtime type identification (RTTI) is also addressed within the
> virtual table, usually within the table's first slot.'
>
> Here I understand that one have some means to access:
> - non-static data members and
> - virtual function of the class object.
>
> But then how one can access the other entities like:
> - static data member
> - static and non-static member functions?
>
> How the above entities are represented with respect to class object
> layout?

The following articles should help:
http://www.eventhelix.com/realtimema...erformance.htm
http://www.eventhelix.com/realtimema...formance2..htm

--
http://www.EventHelix.com/EventStudio
Sequence diagram based systems engineering tool