virtual overloaded functions and base class function call...

[alexandre.braganti]

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

[Bob Hairgrove]

On 10 Mar 2006 06:13:00 -0800, al****************@gmail.com 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
No**********@Home.com

[alexandre.braganti]

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 ;-)

[Jaspreet]

Bob Hairgrove wrote:

On 10 Mar 2006 06:13:00 -0800, al****************@gmail.com 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
No**********@Home.com

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.

[Alf P. Steinbach]

* Bob Hairgrove:

On 10 Mar 2006 06:13:00 -0800, al****************@gmail.com 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]

* 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?

[alexandre.braganti]

anyway, it's not a construction problem as my function is called
largely after all my objects have been fully constructed. Any other
idea ?

[awm129]

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.

[Victor Bazarov]

al****************@gmail.com 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

[Alf P. Steinbach]

* al****************@gmail.com:

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?

[Victor Bazarov]

al****************@gmail.com 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

[Alf P. Steinbach]

* aw****@psualum.com:

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?

[alexandre.braganti]

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

[Victor Bazarov]

al****************@gmail.com 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

[awm129]

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/de...express_74.asp

It should work for what this guy intended. And try to avoid
explainations similar to "Wrong." thanks!

[alexandre.braganti]

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

[Victor Bazarov]

al****************@gmail.com 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]

aw****@psualum.com 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/de...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

[Matthias]

al****************@gmail.com 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]

aw****@psualum.com 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

[alexandre.braganti]

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

That's it.
Sorry for the waste of time, but there was a little difference between
my base function definition and the sub classe one. That's why there
was not really a polymorphism case.

All is clear now.
Many thanks to everybody that waste his time with my issue, especially
for Victor.