C++ Object model layout

Discussion in 'C++' started by sumsin, Jun 11, 2008.

  1. sumsin

    sumsin Guest

    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?
     
    sumsin, Jun 11, 2008
    #1
    1. Advertising

  2. sumsin

    dizzy Guest

    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
     
    dizzy, Jun 11, 2008
    #2
    1. Advertising

  3. sumsin

    Jerry Coffin Guest

    In article <4af52a26-03b6-48f2-b348-82edf5490ba7
    @v1g2000pra.googlegroups.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.
     
    Jerry Coffin, Jun 11, 2008
    #3
  4. sumsin

    sumsin Guest

    On Jun 11, 8:09 pm, Jerry Coffin <> wrote:
    > In article <4af52a26-03b6-48f2-b348-82edf5490ba7
    > @v1g2000pra.googlegroups.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?
     
    sumsin, Jun 11, 2008
    #4
  5. sumsin

    dizzy Guest

    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
     
    dizzy, Jun 11, 2008
    #5
  6. sumsin

    sumsin Guest

    On Jun 11, 8:45 pm, dizzy <> 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!
     
    sumsin, Jun 11, 2008
    #6
  7. sumsin

    sumsin Guest

    On Jun 11, 8:09 pm, Jerry Coffin <> wrote:
    > In article <4af52a26-03b6-48f2-b348-82edf5490ba7
    > @v1g2000pra.googlegroups.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.
     
    sumsin, Jun 11, 2008
    #7
  8. sumsin

    Jerry Coffin Guest

    In article <8a1ec585-3d56-44cf-9b41-1dfb9558e848
    @c19g2000prf.googlegroups.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.
     
    Jerry Coffin, Jun 11, 2008
    #8
  9. sumsin

    James Kanze Guest

    On Jun 11, 5:32 pm, sumsin <> wrote:
    > On Jun 11, 8:09 pm, Jerry Coffin <> wrote:
    > > In article <4af52a26-03b6-48f2-b348-82edf5490ba7
    > > @v1g2000pra.googlegroups.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:
    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
     
    James Kanze, Jun 12, 2008
    #9
  10. On Jun 11, 10:14 am, 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?
    >
    > How the above entities are represented with respect to class object
    > layout?


    The following articles should help:
    http://www.eventhelix.com/realtimemantra/basics/ComparingCPPAndCPerformance.htm
    http://www.eventhelix.com/realtimemantra/basics/ComparingCPPAndCPerformance2..htm

    --
    http://www.EventHelix.com/EventStudio
    Sequence diagram based systems engineering tool
     
    EventHelix.com, Jun 14, 2008
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rick Spiewak
    Replies:
    3
    Views:
    3,196
    Rick Spiewak
    Aug 26, 2003
  2. RobertH
    Replies:
    1
    Views:
    747
    Steve C. Orr [MVP, MCSD]
    Nov 4, 2003
  3. Replies:
    1
    Views:
    621
    John Timney \(MVP\)
    Jun 19, 2006
  4. Replies:
    1
    Views:
    505
    Andreas Wollschlaeger
    Oct 6, 2006
  5. skydrive

    The layout of C++ Object Model

    skydrive, Oct 20, 2011, in forum: C++
    Replies:
    3
    Views:
    582
    Alf P. Steinbach
    Oct 21, 2011
Loading...

Share This Page