C++ Object model layout

[sumsin]

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?

[dizzy]

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

[Victor Bazarov]

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.'

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?

Usually the syntax is <name of the class:: <name of the member>, like

MyClass::myStaticMember

or

MyClass::myStaticFunction(arguments)

And you also can use the 'dot' notation for objects and references and
the 'arrow' notation for pointers to objects if you want to:

MyClass myObject;
MyClass *ptr = &myObject;
... myObject.myStaticMember ...
... ptr->myStaticFunction(arguments) ...

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

The difference between a regular function and a non-static member
function is that the latter has the hidden argument that designates the
object for which it's being called. Inside the non-static member
function the expression 'this' (a non-modifiable lvalue) gives you the
pointer to the object for which the member function is called. Other
than that, the functions are basically all the same.

Static data members are essentially global data. The only difference is
that class members have access specifiers (which regular global data
don't), but this is "only the compile-time feature", IOW it's not
enforced in any way during run-time (once it compiles, no privacy or
other mechanism exists WRT members compared to non-members).

To quote your own text,

Static data members are stored outside the individual class
object.

That means there is no static data in the class object.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jerry Coffin]

In article <4af52a26-03b6-48f2-b348-82edf5490ba7
@v1g2000pra.googlegroups.com>, su*******@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.

[sumsin]

On Jun 11, 8:09 pm, Jerry Coffin <[e-mail]:

In article <4af52a26-03b6-48f2-b348-82edf5490ba7
@v1g2000pra.googlegroups.com>, [e-mail] 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?

[dizzy]

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

[sumsin]

On Jun 11, 8:45 pm, dizzy <[e-mail]:

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!

[sumsin]

On Jun 11, 8:09 pm, Jerry Coffin <[e-mail]:

In article <4af52a26-03b6-48f2-b348-82edf5490ba7
@v1g2000pra.googlegroups.com>, [e-mail] 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.

[Jerry Coffin]

In article <8a1ec585-3d56-44cf-9b41-1dfb9558e848
@c19g2000prf.googlegroups.com>, su*******@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.

[James Kanze]

On Jun 11, 5:32 pm, sumsin <[e-mail]:

On Jun 11, 8:09 pm, Jerry Coffin <[e-mail]:

In article <4af52a26-03b6-48f2-b348-82edf5490ba7
@v1g2000pra.googlegroups.com>, [e-mail] 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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[EventHelix.com]

On Jun 11, 10:14*am, sumsin <[e-mail]:

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