C++ Object Model

Discussion in 'C++' started by al.cpwn@gmail.com, Mar 12, 2006.

  1. Guest

    Which sections of the 2003 standard should I study to understand the
    object model? I am looking to find information similar to that in
    Stanley B. Lippman's book, "Inside the C++ Object Model"
     
    , Mar 12, 2006
    #1
    1. Advertising

  2. peter koch Guest

    skrev:

    > Which sections of the 2003 standard should I study to understand the
    > object model? I am looking to find information similar to that in
    > Stanley B. Lippman's book, "Inside the C++ Object Model"


    If I understand you correctly, no part of the standard will be
    relevant. The standard mandates almost nothing w.r.t. the physical
    layout of objects (the most important exception being that a
    std::vector must be implemented as one contigeous chunk of memory).
    One thing that could tell you about a possible implementation of C++ is
    the C++ performance report. Google for it.

    /Peter
     
    peter koch, Mar 12, 2006
    #2
    1. Advertising

  3. Me Guest

    wrote:
    > Which sections of the 2003 standard should I study to understand the
    > object model? I am looking to find information similar to that in
    > Stanley B. Lippman's book, "Inside the C++ Object Model"


    I'm not really sure what you mean by object model but if it's anything
    like the book, these are the things you need to look for in the
    standard:

    static_cast
    dynamic_cast
    typeid
    virtual functions
    virtual members
    member function pointers
    member data pointers

    and how

    multiple inheritence
    virtual inheritence
    private inheritence

    interacts with the above

    (I believe this is a complete list). The C++ standard just says the
    layout of non-POD classes are implementation defined, so if you're
    looking for any hints by the standard, you're out of luck. But you
    definitely should be aware that C++ allows diamond style inheritence as
    pictured in this iostreams chart:
    http://www.cplusplus.com/ref/iostream/
     
    Me, Mar 12, 2006
    #3
  4. Guest

    peter koch wrote:
    > skrev:
    >
    > > Which sections of the 2003 standard should I study to understand the
    > > object model? I am looking to find information similar to that in
    > > Stanley B. Lippman's book, "Inside the C++ Object Model"

    >
    > If I understand you correctly, no part of the standard will be
    > relevant. The standard mandates almost nothing w.r.t. the physical
    > layout of objects (the most important exception being that a
    > std::vector must be implemented as one contigeous chunk of memory).
    > One thing that could tell you about a possible implementation of C++ is
    > the C++ performance report. Google for it.
    >
    > /Peter


    I recently had an interview for a C++ programmer position and the
    interviewer asked me questions like:

    where does the virtual table reside? (my answer: in memory)
    why don't we make all destructors virtual? (my answer: because they
    will cost memory due to vtable and some classes are not designed to be
    base classes)
    If we add a virtual function to a class will we see an increase in
    class size? (i said yes)
    While size of class grow at constant rate with the addition of each
    virtual function? (i said not sure)

    He then paused and gave me some advice on which books to read, saying
    that I must read "Inside the C++ Object Model". He also said that I
    can't be a good C++ programmer without being a good C programmer. It is
    disappointing because I answered each question to the best of my
    ability. There were some algorithm problems as well but he criticized
    me most for knowledge of C++. So essentially there is no set standard
    for how objects should be represented internally?
     
    , Mar 12, 2006
    #4
  5. Guest

    Me wrote:
    > wrote:
    > > Which sections of the 2003 standard should I study to understand the
    > > object model? I am looking to find information similar to that in
    > > Stanley B. Lippman's book, "Inside the C++ Object Model"

    >
    > I'm not really sure what you mean by object model but if it's anything
    > like the book, these are the things you need to look for in the
    > standard:
    >
    > static_cast
    > dynamic_cast
    > typeid
    > virtual functions
    > virtual members
    > member function pointers
    > member data pointers
    >
    > and how
    >
    > multiple inheritence
    > virtual inheritence
    > private inheritence
    >
    > interacts with the above
    >
    > (I believe this is a complete list). The C++ standard just says the
    > layout of non-POD classes are implementation defined, so if you're
    > looking for any hints by the standard, you're out of luck. But you
    > definitely should be aware that C++ allows diamond style inheritence as
    > pictured in this iostreams chart:
    > http://www.cplusplus.com/ref/iostream/


    Thank you, I'll read these and get back with any questions.
     
    , Mar 12, 2006
    #5
  6. benben Guest

    > I recently had an interview for a C++ programmer position and the
    > interviewer asked me questions like:
    >
    > where does the virtual table reside? (my answer: in memory)


    Correct. Static memory most likely.

    > why don't we make all destructors virtual? (my answer: because they
    > will cost memory due to vtable and some classes are not designed to be
    > base classes)


    Correct.

    > If we add a virtual function to a class will we see an increase in
    > class size? (i said yes)


    You have to ask him back what he means by "class size". If what he
    refers to is the size of memory allocated for an object of such a class.

    If he agrees you have to ask him whether there is already a virtual
    function in such a class. If the answer is yes then there is unlikely a
    change in "size"; otherwise an increase in the size is possible.

    > While size of class grow at constant rate with the addition of each
    > virtual function? (i said not sure)


    Again you need a better definition for "class size". If that means the
    size of the static memory needed to support such a class (such that
    reserved for class information especially concerning the virtual
    functions) then the answer is yes. If the term means what I assumed in
    the previous paragraph, it is unlikely. Again this is highly
    implementation dependent.

    > He then paused and gave me some advice on which books to read, saying
    > that I must read "Inside the C++ Object Model". He also said that I
    > can't be a good C++ programmer without being a good C programmer. It is
    > disappointing because I answered each question to the best of my
    > ability. There were some algorithm problems as well but he criticized
    > me most for knowledge of C++. So essentially there is no set standard
    > for how objects should be represented internally?


    If that's his reason to dismiss you then you may be better off being
    dismissed. The interviewer as described seems to have a screw loose in
    his head.

    Regards,
    Ben
     
    benben, Mar 13, 2006
    #6
  7. Me Guest

    wrote:
    > > > Which sections of the 2003 standard should I study to understand the
    > > > object model? I am looking to find information similar to that in
    > > > Stanley B. Lippman's book, "Inside the C++ Object Model"

    >
    > I recently had an interview for a C++ programmer position and the
    > interviewer asked me questions like:
    >
    > where does the virtual table reside? (my answer: in memory)


    This question assumes the compiler implements virtual functions as an
    array of function pointers. The implementations listed in Lippman's
    book (from memory and it's been a long while since I last read it) turn
    the following:

    class foo {
    virtual void fn();
    data d;
    };

    into one of (ignoring std::type_info):

    // table inlined at the beginning
    struct foo {
    void (*fn)(foo*);
    data d;
    };

    // table inlined at the end
    struct foo {
    data d;
    void (*fn)(foo*);
    };


    struct foo_vtbl {
    void (*fn)(foo*);
    };

    // vtable at beginning
    struct foo {
    const foo_vtbl *vtbl;
    data d;
    };

    // vtable at end
    struct foo {
    data d;
    const foo_vtbl *vtbl;
    };

    There are tons of other possible choices. One possibility is to keep
    track of all RTTI objects in a giant global table and do a lookup based
    on the address and then call the desired function based on a switch
    statement. This has the advantage of requiring no storage inside the
    class at all.

    > If we add a virtual function to a class will we see an increase in
    > class size? (i said yes)
    > While size of class grow at constant rate with the addition of each
    > virtual function? (i said not sure)


    These two questions support my assumption about those 4 implementations
    above. You can see that if we inline the table, the class size
    increases, but if we use a vtable, the class size stays constant.

    For multiple/virtual inheritance with virtual data members this gets
    much more complicated and it really depends on how the implementation
    ties all the things required by the C++ standard together to see if
    adding a virtual function in some base class increases the size.

    > He then paused and gave me some advice on which books to read, saying
    > that I must read "Inside the C++ Object Model". He also said that I
    > can't be a good C++ programmer without being a good C programmer.


    This guy sounds like one of those people that gets really familiar with
    how their compiler implements things and then makes all sorts of
    non-standard conforming/portable assumptions instead of what the
    standard actually guarantees. (I'd recommend getting the book though, I
    used it to learn C++ but it definitely shouldn't be used as a
    substitute for the C++ standard)

    > It is disappointing because I answered each question to the best of my
    > ability. There were some algorithm problems as well but he criticized
    > me most for knowledge of C++. So essentially there is no set standard
    > for how objects should be represented internally?


    A C++ implementation may be required to follow some ABI for backwards
    compatibility/interoperability reasons, but as far as the C++ standard
    is concerned, the answer is no and the examples given in the book were
    pretty much cfront centric and designed to be easily ported. Non-cfront
    compilers have the advantage of knowing the machine model and can do
    all sorts of evil tricks like using thunks.
     
    Me, Mar 13, 2006
    #7
  8. peter koch Guest

    skrev:

    > peter koch wrote:

    [snip]
    >
    > I recently had an interview for a C++ programmer position and the
    > interviewer asked me questions like:
    >
    > where does the virtual table reside? (my answer: in memory)
    > why don't we make all destructors virtual? (my answer: because they
    > will cost memory due to vtable and some classes are not designed to be
    > base classes)
    > If we add a virtual function to a class will we see an increase in
    > class size? (i said yes)
    > While size of class grow at constant rate with the addition of each
    > virtual function? (i said not sure)
    >
    > He then paused and gave me some advice on which books to read, saying
    > that I must read "Inside the C++ Object Model". He also said that I
    > can't be a good C++ programmer without being a good C programmer. It is
    > disappointing because I answered each question to the best of my
    > ability. There were some algorithm problems as well but he criticized
    > me most for knowledge of C++. So essentially there is no set standard
    > for how objects should be represented internally?


    Nope - there is no standard layout of objects in C++. It is up to the
    implementers of the particular compiler to find the smartest way to
    store their data.
    Apart from this, I really am not sure that I agree with your
    interviewer.... knowledge of C is okay, but if it makes you program as
    if you were programming in C, you would have been better off with no
    knowledge of C. Still, being aware of what goes on "beneath" the C++
    layer is a huge advantage when optimising and debugging programs.

    Kind regards
    Peter
     
    peter koch, Mar 13, 2006
    #8
  9. Student Guest

    Hi all,
    I also got a lot of infor on this. But as every body has told it's not
    true that C knowledge is required for the C++. I know people starting
    from C++ and with no knowledge of C. Well it's a thinking that C++ is a
    different language although it started as a superset of C. Well
    currently i am trying to implement a subset of C++(As an assignment). I
    think i should make it so that people can see what internally happens.
    Please provide me comment on how to make it? Like how to design it so
    that people can easily understand it. and whicl all things to refer for
    it.
    Tahnks
     
    Student, Mar 13, 2006
    #9
    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. =?Utf-8?B?c2NvdHRybQ==?=

    is there an object oriented design model asp.net?

    =?Utf-8?B?c2NvdHRybQ==?=, Feb 24, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    494
    =?Utf-8?B?c2NvdHRybQ==?=
    Feb 27, 2004
  2. Tarllem
    Replies:
    2
    Views:
    336
    MasterGaurav
    Mar 3, 2005
  3. =?Utf-8?B?UGF1bA==?=

    General question about component object model COM

    =?Utf-8?B?UGF1bA==?=, Oct 12, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    362
    =?Utf-8?B?UGF1bA==?=
    Oct 12, 2005
  4. Sudsy
    Replies:
    0
    Views:
    541
    Sudsy
    Jul 3, 2003
  5. Replies:
    1
    Views:
    517
    Andreas Wollschlaeger
    Oct 6, 2006
Loading...

Share This Page