virtual overloaded functions and base class function call...

Discussion in 'C++' started by alexandre.braganti@gmail.com, Mar 10, 2006.

  1. Guest

    Hello,
    First sorry for my poor English, I am French ;-)
    I've got a comprehension problem of what happend in one of the project
    i'm working on.

    Basically I've got a class gs_object than has got a VIRTUAL function
    createList(). This createList() function is overloaded in another class
    named ct_server that inherits gs_object.

    in my code, it looks something like that :

    class gs_object {
    ...
    virtual void createList();
    ...
    };

    class ct_server : public gs_object {
    ...
    virtual void createList();

    void initInstance();
    ...
    };

    Here is the problem :

    in the function ct_server::initInstance, one boy of my team wanted to
    call the gs_object::createList() base function, and not the overloaded
    one (ct_server::createList() ). But, according to me he made a mistake
    as he wrote :

    (static_cast<GS_object*>(this))->createList();

    instead of

    gs_object::createList();


    According to me, as createList() is virtual, this line of code should
    call ct_server::createList and not gs_object::createList()

    But it doesn't : when in run in debug mode, i can see it calls
    gs_object::createList();

    I can't understand why. Could you explain me ?
    FYI, i'm using Visual C++ 7.1.3 ; Qt 3.3.4
    , Mar 10, 2006
    #1
    1. Advertising

  2. On 10 Mar 2006 06:13:00 -0800, wrote:

    >Hello,
    >First sorry for my poor English, I am French ;-)
    >I've got a comprehension problem of what happend in one of the project
    >i'm working on.
    >
    >Basically I've got a class gs_object than has got a VIRTUAL function
    >createList(). This createList() function is overloaded in another class
    >named ct_server that inherits gs_object.
    >
    >in my code, it looks something like that :
    >
    >class gs_object {
    > ...
    > virtual void createList();
    > ...
    >};
    >
    >class ct_server : public gs_object {
    > ...
    > virtual void createList();
    >
    > void initInstance();
    > ...
    >};
    >
    >Here is the problem :
    >
    >in the function ct_server::initInstance, one boy of my team wanted to
    >call the gs_object::createList() base function, and not the overloaded
    >one (ct_server::createList() ). But, according to me he made a mistake
    >as he wrote :
    >
    >(static_cast<GS_object*>(this))->createList();
    >
    >instead of
    >
    >gs_object::createList();
    >
    >
    >According to me, as createList() is virtual, this line of code should
    >call ct_server::createList and not gs_object::createList()
    >
    >But it doesn't : when in run in debug mode, i can see it calls
    >gs_object::createList();
    >
    >I can't understand why. Could you explain me ?
    >FYI, i'm using Visual C++ 7.1.3 ; Qt 3.3.4


    Where is ct_server::initInstance() called? If it is called in the
    constructor of the ct_server object, it is entirely possible that the
    base class version is called because the object has not yet finished
    construction. However, I'm not sure that this is guaranteed to happen
    by the C++ standard; it might be implementation-defined.

    --
    Bob Hairgrove
    Bob Hairgrove, Mar 10, 2006
    #2
    1. Advertising

  3. Guest

    thanks for your answer, but I already thought to this issue : NO the
    initInstance is NOT called in the constructor of the class... :-/

    Any other idea ?


    PS: i made a basic project with only 2 classes under Visual Studio in
    order to check it again, and now I've not the same result at all : It
    calls well ct_server::createList()... in my 'basic' project.

    I'm becoming crazy ;-)
    , Mar 10, 2006
    #3
  4. Jaspreet Guest

    Bob Hairgrove wrote:
    > On 10 Mar 2006 06:13:00 -0800, wrote:
    >
    > >Hello,
    > >First sorry for my poor English, I am French ;-)
    > >I've got a comprehension problem of what happend in one of the project
    > >i'm working on.
    > >
    > >Basically I've got a class gs_object than has got a VIRTUAL function
    > >createList(). This createList() function is overloaded in another class
    > >named ct_server that inherits gs_object.
    > >
    > >in my code, it looks something like that :
    > >
    > >class gs_object {
    > > ...
    > > virtual void createList();
    > > ...
    > >};
    > >
    > >class ct_server : public gs_object {
    > > ...
    > > virtual void createList();
    > >
    > > void initInstance();
    > > ...
    > >};
    > >
    > >Here is the problem :
    > >
    > >in the function ct_server::initInstance, one boy of my team wanted to
    > >call the gs_object::createList() base function, and not the overloaded
    > >one (ct_server::createList() ). But, according to me he made a mistake
    > >as he wrote :
    > >
    > >(static_cast<GS_object*>(this))->createList();
    > >
    > >instead of
    > >
    > >gs_object::createList();
    > >
    > >
    > >According to me, as createList() is virtual, this line of code should
    > >call ct_server::createList and not gs_object::createList()
    > >
    > >But it doesn't : when in run in debug mode, i can see it calls
    > >gs_object::createList();
    > >
    > >I can't understand why. Could you explain me ?
    > >FYI, i'm using Visual C++ 7.1.3 ; Qt 3.3.4

    >
    > Where is ct_server::initInstance() called? If it is called in the
    > constructor of the ct_server object, it is entirely possible that the
    > base class version is called because the object has not yet finished
    > construction. However, I'm not sure that this is guaranteed to happen
    > by the C++ standard; it might be implementation-defined.
    >
    > --
    > Bob Hairgrove
    >


    I guess calling a virtual function in the constructor is undefined
    behaviour. That is because the vtbl is still not fully constructed by
    that time.
    Jaspreet, Mar 10, 2006
    #4
  5. * Bob Hairgrove:
    > On 10 Mar 2006 06:13:00 -0800, wrote:
    >
    >> Hello,
    >> First sorry for my poor English, I am French ;-)
    >> I've got a comprehension problem of what happend in one of the project
    >> i'm working on.
    >>
    >> Basically I've got a class gs_object than has got a VIRTUAL function
    >> createList(). This createList() function is overloaded in another class
    >> named ct_server that inherits gs_object.
    >>
    >> in my code, it looks something like that :
    >>
    >> class gs_object {
    >> ...
    >> virtual void createList();
    >> ...
    >> };
    >>
    >> class ct_server : public gs_object {
    >> ...
    >> virtual void createList();
    >>
    >> void initInstance();
    >> ...
    >> };
    >>
    >> Here is the problem :
    >>
    >> in the function ct_server::initInstance, one boy of my team wanted to
    >> call the gs_object::createList() base function, and not the overloaded
    >> one (ct_server::createList() ). But, according to me he made a mistake
    >> as he wrote :
    >>
    >> (static_cast<GS_object*>(this))->createList();
    >>
    >> instead of
    >>
    >> gs_object::createList();
    >>
    >>
    >> According to me, as createList() is virtual, this line of code should
    >> call ct_server::createList and not gs_object::createList()
    >>
    >> But it doesn't : when in run in debug mode, i can see it calls
    >> gs_object::createList();
    >>
    >> I can't understand why. Could you explain me ?
    >> FYI, i'm using Visual C++ 7.1.3 ; Qt 3.3.4

    >
    > Where is ct_server::initInstance() called? If it is called in the
    > constructor of the ct_server object, it is entirely possible that the
    > base class version is called because the object has not yet finished
    > construction. However, I'm not sure that this is guaranteed to happen
    > by the C++ standard; it might be implementation-defined.


    It's guaranteed by the standard, and it's in the FAQ somewhere, and I
    think your explanation is the most likely for the OP's case.

    But anyway the programmer made an error: casting the this-pointer does
    not affect which implementation is executed for a virtual function.

    There's also a FAQ for the case where one really does want derived class
    defined behavior during construction of a base class, called Dynamic
    Binding During Construction (or some such, I don't exactly recall, since
    I wanted to call it "virtual construction", but that term was already
    used to denote what I'd want to call "cloning" -- oh well).

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Mar 10, 2006
    #5
  6. * Jaspreet:
    >
    > I guess calling a virtual function in the constructor is undefined
    > behaviour. That is because the vtbl is still not fully constructed by
    > that time.


    Nope.

    Check the FAQ.

    Or the nearest textbook.



    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Mar 10, 2006
    #6
  7. wrote:
    > thanks for your answer, but I already thought to this issue : NO the
    > initInstance is NOT called in the constructor of the class... :-/
    >
    > Any other idea ?
    >
    >
    > PS: i made a basic project with only 2 classes under Visual Studio in
    > order to check it again, and now I've not the same result at all : It
    > calls well ct_server::createList()... in my 'basic' project.
    >
    > I'm becoming crazy ;-)


    Maybe. This program:
    ----------------------------------
    #include <iostream>
    using namespace std;

    struct A {
    virtual void foo(int i) {
    cout << "A::foo(" << i << ")\n";
    }
    };

    struct B : A {
    virtual void foo(int i) {
    cout << "B::foo(" << i << ")\n";
    }
    void bar(int i) {
    (static_cast<A*>(this))->foo(i);
    this->A::foo(i);
    }
    };

    int main() {
    B b;
    b.bar(42);
    }
    ----------------------------------
    Should output:
    B::(42)
    A::(42)

    And it does with VC++ v7.1 and VC++ v8 (and I stopped checking after
    those). You must be (hopefully unintentionally) providing incorrect
    information to us or collecting it from your colleague. Revisit your
    own code.

    V
    --
    Please remove capital As from my address when replying by mail
    Victor Bazarov, Mar 10, 2006
    #7
  8. Guest

    anyway, it's not a construction problem as my function is called
    largely after all my objects have been fully constructed. Any other
    idea ?
    , Mar 10, 2006
    #8
  9. Guest

    let me make sure I understand your question... you want to know why

    (static_cast<GS_object*>(this))->createList();

    calls createList() in the gs_object class, correct?

    Virtual function calls all depend on the *run time* type of the object.
    Your team mate is changing the run time type of the 'this' pointer
    before making the call to createList. By casting the 'this' pointer to
    a GS_object pointer, the 'this' no longer points to the ct_server
    object, it now points to the gs_object object from which it was derived
    and only has knowlege of functions within the gs_object class. This is
    why then calling createList calls the createList function in the base
    class.



    The method you suggested:

    gs_object::createList();

    is also correct. This line translates into:

    this -> gs_object::createList();

    In this case, the correct function is determined by the compiler at
    *compile time*. The 'this' pointer in this case still refers to an
    object of type gs_object and you specify exactly which createList()
    function to call. In my option, this method is preferable. Recasting
    a this pointer can lead to strange behavior later in the function. It
    can also cause strange run time bugs.


    Hope this cleared things up for ya.
    , Mar 10, 2006
    #9
  10. wrote:
    > anyway, it's not a construction problem as my function is called
    > largely after all my objects have been fully constructed. Any other
    > idea ?


    Go back to your project and find out more. Your explanation didn't hold
    water.

    V
    --
    Please remove capital As from my address when replying by mail
    Victor Bazarov, Mar 10, 2006
    #10
  11. * :
    > anyway, it's not a construction problem as my function is called
    > largely after all my objects have been fully constructed. Any other
    > idea ?


    What does 'largely' mean?

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Mar 10, 2006
    #11
  12. * :
    > let me make sure I understand your question... you want to know why
    >
    > (static_cast<GS_object*>(this))->createList();
    >
    > calls createList() in the gs_object class, correct?
    >
    > Virtual function calls all depend on the *run time* type of the object.


    Right.


    > Your team mate is changing the run time type of the 'this' pointer
    > before making the call to createList. By casting the 'this' pointer to
    > a GS_object pointer, the 'this' no longer points to the ct_server
    > object, it now points to the gs_object object from which it was derived
    > and only has knowlege of functions within the gs_object class. This is
    > why then calling createList calls the createList function in the base
    > class.


    Wrong.


    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Mar 10, 2006
    #12
  13. Guest

    > let me make sure I understand your question... you want to know why
    > (static_cast<GS_object*>(this))->createList();
    > calls createList() in the gs_object class, correct?


    Yes, that's it.

    > Virtual function calls all depend on the *run time* type of the object.


    I agree.

    > Your team mate is changing the run time type of the 'this' pointer
    > before making the call to createList. By casting the 'this' pointer to
    > a GS_object pointer, the 'this' no longer points to the ct_server
    > object, it now points to the gs_object object from which it was derived
    > and only has knowlege of functions within the gs_object class. This is
    > why then calling createList calls the createList function in the base
    > class.


    I do NOT agree : if I do something like this :

    GSObject* myObj = (GSOject*) myCtServer
    myObj->createList();

    .... will call ct_server::createList altought myObj is a pointer on a
    GSObject object. That why someone invented virtuals functions ;-)
    am I right ?

    So, according to me,
    (static_cast<GS_object*>(this))->createList();
    is equivalent to :
    GSObject* myObj = (GSOject*) myCtServer
    myObj->createList();

    In that case (static_cast<GS_object*>(this))->createList(); should call
    ct_server::createList') and not gsobject::createList().

    That the way I see it. That's NOT the way it works in my project :-/

    Anyway, another basic project I've made (like the 'foo/bar' one of
    Victor) give me all expected results.

    That's why I don't understand what's happening with my original project
    at all...
    , Mar 10, 2006
    #13
  14. wrote:
    > [..]
    > That's why I don't understand what's happening with my original project
    > at all...


    Neither do we, since we aren't exposed to your original project. It's up
    to you to solve it unless you want to post the entire project.

    Start removing irrelevant code (or code that you think is irrelevant) and
    see if the behaviour is still there. If you arrive at the same two-class
    project, like in my example, and it still exhibits the "wrong" behaviour,
    post it. I'll bet that the error is elsewhere, and by the time you get to
    the minimal code that reproduces the problem, you will have solved the
    mystery.

    V
    --
    Please remove capital As from my address when replying by mail
    Victor Bazarov, Mar 10, 2006
    #14
  15. Guest

    Well I'm all wet. Thats what I get for relying on microsoft's
    definition of static_cast before actually trying it. I ran something
    similar to the example above and my results differed from what the
    original post was describing. So, as I'm obviously wrong, can someone
    explain why the static_cast doesn't work? Acording to microsoft:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/express_74.asp

    It should work for what this guy intended. And try to avoid
    explainations similar to "Wrong." thanks!
    , Mar 10, 2006
    #15
  16. Guest

    It's not so easy to remove irrelevant things in my project, or to post
    it as it's a commercial project of more than 200 000 lines of code.

    That's why i decided to post in this group : maybe someone else has
    already had that kind of behavior and could tell me more about what's
    happening...
    , Mar 10, 2006
    #16
  17. wrote:
    > It's not so easy to remove irrelevant things in my project, or to post
    > it as it's a commercial project of more than 200 000 lines of code.


    Nobody said the life was easy.

    > That's why i decided to post in this group : maybe someone else has
    > already had that kind of behavior and could tell me more about what's
    > happening...


    Your investigation about what's happening and why seems to be incomplete.

    You claim that your colleague made some particular change that allegedly
    caused a call to a virtual function to be resolved non-polymorphically.
    Since it is well-known (by you as well) that such change should not affect
    the outcome in the way claimed, the only two explanations are (a) the call
    is [now] made from the constructor or destructor and (b) there is
    a serious bug in the compiler. Since you have dismissed the former, and
    the latter is _extremely_ unlikely, the only logical conclusion is that
    you're mistaken and either your explanation is incorrect or your dismissal
    of (a) is unfounded. That's why I said what I said, go back to your
    project and look at it again, paying more attention. Perhaps the function
    being called is _not_ the one that is overridden in the derived class due
    to the difference in the arguments or some such. Perhaps the static_cast
    is not the only difference between the project before and after it started
    working "correctly".

    The ball is in your court. We cannot do anything without seeing the code.
    All our guesses are a waste of time.

    V
    --
    Please remove capital As from my address when replying by mail
    Victor Bazarov, Mar 10, 2006
    #17
  18. wrote:
    > Well I'm all wet. Thats what I get for relying on microsoft's
    > definition of static_cast before actually trying it. I ran something
    > similar to the example above and my results differed from what the
    > original post was describing. So, as I'm obviously wrong, can someone
    > explain why the static_cast doesn't work? Acording to microsoft:
    >
    > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/express_74.asp
    >
    > It should work for what this guy intended.


    No.

    What in the explanation on MSDN leads you to believe that? I don't see
    anything different on MSDN from how 'static_cast' is supposed to work (if
    you look in the Standard).

    > And try to avoid
    > explainations similar to "Wrong." thanks!


    Wrong. You're welcome!

    V
    --
    Please remove capital As from my address when replying by mail
    Victor Bazarov, Mar 10, 2006
    #18
  19. Matthias Guest

    wrote:
    > That's why i decided to post in this group : maybe someone else has
    > already had that kind of behavior and could tell me more about what's
    > happening...


    Just a far fetched idea: Maybe this function exists in more versions
    because you are using function overloading. If you have an bug there
    this might cause the polymorphism seeming to fail...

    Regards,
    Matthias
    Matthias, Mar 10, 2006
    #19
  20. Matthias Guest

    wrote:

    > Well I'm all wet. Thats what I get for relying on microsoft's
    > definition of static_cast before actually trying it.


    A cast changes the type of the pointer. But this does not have impact
    on which virtual function is actually being called. That's what virtual
    functions/polymorphism is all about...

    Regards,
    Matthias
    Matthias, Mar 10, 2006
    #20
    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.

Share This Page