Dynamic binding inside constructor for virtual Function in C++
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
As per the standard, we know that constructor always go for an early binding of a virtual function inside them because they don't have complete idea the derived class hierarchy downside.
In this case if early binding is used inside my base constructor, I have passed a derived object to a base class pointer which is completely acceptable (an upcasting is done here). If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer(the object pointed by the pointer because we don't know the exact object being pointed). In that case since the pointer type is Base * we should have invoked only Base class virtual function in both cases. Could some one please clarify this?
I think dynamic binding is used here rather than early binding. Please correct me if my understanding is wrong.
The first line of the output which invokes base is completely fine
class Base
{
public:
Base(){
fun();
}
Base(Base *p)
{
p->fun();
}
virtual void fun()
{
cout<<"In Base"<<endl;
}
};
class Derived : public Base
{
public:
void fun()
{
cout<<"In Derived"<<endl;
}
};
int main()
{
Derived d;
Base b(&d);
}
O/P :
In Base
In Derived
c++ constructor virtual-functions
add a comment |
As per the standard, we know that constructor always go for an early binding of a virtual function inside them because they don't have complete idea the derived class hierarchy downside.
In this case if early binding is used inside my base constructor, I have passed a derived object to a base class pointer which is completely acceptable (an upcasting is done here). If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer(the object pointed by the pointer because we don't know the exact object being pointed). In that case since the pointer type is Base * we should have invoked only Base class virtual function in both cases. Could some one please clarify this?
I think dynamic binding is used here rather than early binding. Please correct me if my understanding is wrong.
The first line of the output which invokes base is completely fine
class Base
{
public:
Base(){
fun();
}
Base(Base *p)
{
p->fun();
}
virtual void fun()
{
cout<<"In Base"<<endl;
}
};
class Derived : public Base
{
public:
void fun()
{
cout<<"In Derived"<<endl;
}
};
int main()
{
Derived d;
Base b(&d);
}
O/P :
In Base
In Derived
c++ constructor virtual-functions
"we know that constructor always go for an early binding" wrong
– curiousguy
Nov 24 '18 at 10:38
add a comment |
As per the standard, we know that constructor always go for an early binding of a virtual function inside them because they don't have complete idea the derived class hierarchy downside.
In this case if early binding is used inside my base constructor, I have passed a derived object to a base class pointer which is completely acceptable (an upcasting is done here). If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer(the object pointed by the pointer because we don't know the exact object being pointed). In that case since the pointer type is Base * we should have invoked only Base class virtual function in both cases. Could some one please clarify this?
I think dynamic binding is used here rather than early binding. Please correct me if my understanding is wrong.
The first line of the output which invokes base is completely fine
class Base
{
public:
Base(){
fun();
}
Base(Base *p)
{
p->fun();
}
virtual void fun()
{
cout<<"In Base"<<endl;
}
};
class Derived : public Base
{
public:
void fun()
{
cout<<"In Derived"<<endl;
}
};
int main()
{
Derived d;
Base b(&d);
}
O/P :
In Base
In Derived
c++ constructor virtual-functions
As per the standard, we know that constructor always go for an early binding of a virtual function inside them because they don't have complete idea the derived class hierarchy downside.
In this case if early binding is used inside my base constructor, I have passed a derived object to a base class pointer which is completely acceptable (an upcasting is done here). If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer(the object pointed by the pointer because we don't know the exact object being pointed). In that case since the pointer type is Base * we should have invoked only Base class virtual function in both cases. Could some one please clarify this?
I think dynamic binding is used here rather than early binding. Please correct me if my understanding is wrong.
The first line of the output which invokes base is completely fine
class Base
{
public:
Base(){
fun();
}
Base(Base *p)
{
p->fun();
}
virtual void fun()
{
cout<<"In Base"<<endl;
}
};
class Derived : public Base
{
public:
void fun()
{
cout<<"In Derived"<<endl;
}
};
int main()
{
Derived d;
Base b(&d);
}
O/P :
In Base
In Derived
c++ constructor virtual-functions
c++ constructor virtual-functions
asked Nov 16 '18 at 15:06
user2906818user2906818
123
123
"we know that constructor always go for an early binding" wrong
– curiousguy
Nov 24 '18 at 10:38
add a comment |
"we know that constructor always go for an early binding" wrong
– curiousguy
Nov 24 '18 at 10:38
"we know that constructor always go for an early binding" wrong
– curiousguy
Nov 24 '18 at 10:38
"we know that constructor always go for an early binding" wrong
– curiousguy
Nov 24 '18 at 10:38
add a comment |
2 Answers
2
active
oldest
votes
The rule for virtual calls within a constructor body applies to an object currently being constructed, because that object is not yet considered to be an object of any derived class. (And there's a similar rule for an object currently being destroyed.) It has little to do with "early binding" in the sense of using a compile-time type, such as the syntax ClassName::member_func() forces.
Your code has two different objects d and b, and the constructor of d has entirely finished by the time you get to the p->fun(); line.
In detail:
- The program enters
main. - The object
dis created using the implicitly declared default constructor ofDerived. - The first thing
Derived::Derived()does is create the base class subobject, by calling the default constructorBase::Base(). - The body of
Base::Base()callsfun(). Since we have not yet entered the body of theDerived::Derived()constructor, this virtual lookup invokesBase::fun().
Base::Base()finishes.- The body of
Derived::Derived(), which is empty, executes and finishes. - Back in
main, the objectbis created by passing a pointer todto the constructorBase::Base(Base*). - The body of
Base::Base(Base *p)callsp->fun(). Sincepis a pointer tod, which is already a completely constructed object of typeDerived, this virtual lookup invokesDerived::fun().
Contrast with this slightly different example, where we define a default constructor of Derived to pass this (implicitly converted to Base*) to the constructor for the Base subobject. (This is valid, though could be risky if the pointer were used in other ways, such as in an initializer for a base or member of Base.)
#include <iostream>
using std::cout;
using std::endl;
class Base
{
public:
Base(){
fun();
}
Base(Base *p)
{
p->fun();
}
virtual void fun()
{
cout<<"In Base"<<endl;
}
};
class Derived
{
public:
Derived() : Base(this) {}
virtual void fun() override
{
cout << "In Derived" << endl;
}
};
int main()
{
Derived d;
}
This program will print just "In Base", since now in Base::Base(Base *p), p does point at the same object which is currently being constructed.
@aschelper, very nice explanation. As per your last statement "this" which is sent to base class constructor has the value of derived object or base object?
– user2906818
Nov 16 '18 at 16:12
@user2906818 neither, a pointer is a distinct value to the thing it points to. At that point it is an invalid pointer-to-derived that is implicitly convertible to a valid pointer-to-base. In the body of the constructor it is a valid pointer-to-derived
– Caleth
Nov 16 '18 at 16:50
"The "early binding" rule you describe applies to an object currently being constructed" What do you mean by "early binding"?
– curiousguy
Nov 19 '18 at 21:37
@curiousguy That's how the OP described it, though I've never heard the term before.
– aschepler
Nov 20 '18 at 1:47
@aschepler Early binding means that the function called is selected by on the types of the expressions used, at compile time ("early"); as the OP puts it: "If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer"
– curiousguy
Nov 20 '18 at 2:17
|
show 1 more comment
The reason is that C++ classes are constructed from Base classes to derived classes and virtual call table of the complete object is created when the object creation process is completed. Therefore, the base class function is called in the code excerpt above. Unless otherwise mandatory, you should never make virtual function calls in the constructor. Below is an excerpt from Bjarne Stroustrup's C++ Style and Technique FAQ:
In a constructor, the virtual call mechanism is disabled because
overriding from derived classes hasn’t yet happened. Objects are constructed from the base up, “base before derived”.Destruction is done “derived class before base class”, so virtual
functions behave as in constructors: Only the local definitions are used –
and no calls are made to overriding functions to avoid touching the (now
destroyed) derived class part of the object.
Very Nice explanantion. So you mean when we are constructing the derived object for the first time we enter in to the default Base constructor and since the derived object is not yet constructed by that time we go for an early binding and call the Base Virtual function. IN the second case since we have the derived object which is already formed we go for a dynamic binding here and hence call Derived virtual function. Please correct me if my understanding is wrong
– user2906818
Nov 16 '18 at 16:21
yes, this is exactly what I meant to explain.
– Can Yuce
Nov 16 '18 at 16:37
@user2906818 "we go for an early binding" no, we go for a virtual call based on the real type of the object, as always
– curiousguy
Nov 19 '18 at 21:59
"the virtual call mechanism is disabled" no
– curiousguy
Nov 19 '18 at 22:02
@curiousguy Did you check Bjarne Stroustrup's C++ Style and Technique FAQ?
– Can Yuce
Nov 21 '18 at 0:08
|
show 6 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53340431%2fdynamic-binding-inside-constructor-for-virtual-function-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The rule for virtual calls within a constructor body applies to an object currently being constructed, because that object is not yet considered to be an object of any derived class. (And there's a similar rule for an object currently being destroyed.) It has little to do with "early binding" in the sense of using a compile-time type, such as the syntax ClassName::member_func() forces.
Your code has two different objects d and b, and the constructor of d has entirely finished by the time you get to the p->fun(); line.
In detail:
- The program enters
main. - The object
dis created using the implicitly declared default constructor ofDerived. - The first thing
Derived::Derived()does is create the base class subobject, by calling the default constructorBase::Base(). - The body of
Base::Base()callsfun(). Since we have not yet entered the body of theDerived::Derived()constructor, this virtual lookup invokesBase::fun().
Base::Base()finishes.- The body of
Derived::Derived(), which is empty, executes and finishes. - Back in
main, the objectbis created by passing a pointer todto the constructorBase::Base(Base*). - The body of
Base::Base(Base *p)callsp->fun(). Sincepis a pointer tod, which is already a completely constructed object of typeDerived, this virtual lookup invokesDerived::fun().
Contrast with this slightly different example, where we define a default constructor of Derived to pass this (implicitly converted to Base*) to the constructor for the Base subobject. (This is valid, though could be risky if the pointer were used in other ways, such as in an initializer for a base or member of Base.)
#include <iostream>
using std::cout;
using std::endl;
class Base
{
public:
Base(){
fun();
}
Base(Base *p)
{
p->fun();
}
virtual void fun()
{
cout<<"In Base"<<endl;
}
};
class Derived
{
public:
Derived() : Base(this) {}
virtual void fun() override
{
cout << "In Derived" << endl;
}
};
int main()
{
Derived d;
}
This program will print just "In Base", since now in Base::Base(Base *p), p does point at the same object which is currently being constructed.
@aschelper, very nice explanation. As per your last statement "this" which is sent to base class constructor has the value of derived object or base object?
– user2906818
Nov 16 '18 at 16:12
@user2906818 neither, a pointer is a distinct value to the thing it points to. At that point it is an invalid pointer-to-derived that is implicitly convertible to a valid pointer-to-base. In the body of the constructor it is a valid pointer-to-derived
– Caleth
Nov 16 '18 at 16:50
"The "early binding" rule you describe applies to an object currently being constructed" What do you mean by "early binding"?
– curiousguy
Nov 19 '18 at 21:37
@curiousguy That's how the OP described it, though I've never heard the term before.
– aschepler
Nov 20 '18 at 1:47
@aschepler Early binding means that the function called is selected by on the types of the expressions used, at compile time ("early"); as the OP puts it: "If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer"
– curiousguy
Nov 20 '18 at 2:17
|
show 1 more comment
The rule for virtual calls within a constructor body applies to an object currently being constructed, because that object is not yet considered to be an object of any derived class. (And there's a similar rule for an object currently being destroyed.) It has little to do with "early binding" in the sense of using a compile-time type, such as the syntax ClassName::member_func() forces.
Your code has two different objects d and b, and the constructor of d has entirely finished by the time you get to the p->fun(); line.
In detail:
- The program enters
main. - The object
dis created using the implicitly declared default constructor ofDerived. - The first thing
Derived::Derived()does is create the base class subobject, by calling the default constructorBase::Base(). - The body of
Base::Base()callsfun(). Since we have not yet entered the body of theDerived::Derived()constructor, this virtual lookup invokesBase::fun().
Base::Base()finishes.- The body of
Derived::Derived(), which is empty, executes and finishes. - Back in
main, the objectbis created by passing a pointer todto the constructorBase::Base(Base*). - The body of
Base::Base(Base *p)callsp->fun(). Sincepis a pointer tod, which is already a completely constructed object of typeDerived, this virtual lookup invokesDerived::fun().
Contrast with this slightly different example, where we define a default constructor of Derived to pass this (implicitly converted to Base*) to the constructor for the Base subobject. (This is valid, though could be risky if the pointer were used in other ways, such as in an initializer for a base or member of Base.)
#include <iostream>
using std::cout;
using std::endl;
class Base
{
public:
Base(){
fun();
}
Base(Base *p)
{
p->fun();
}
virtual void fun()
{
cout<<"In Base"<<endl;
}
};
class Derived
{
public:
Derived() : Base(this) {}
virtual void fun() override
{
cout << "In Derived" << endl;
}
};
int main()
{
Derived d;
}
This program will print just "In Base", since now in Base::Base(Base *p), p does point at the same object which is currently being constructed.
@aschelper, very nice explanation. As per your last statement "this" which is sent to base class constructor has the value of derived object or base object?
– user2906818
Nov 16 '18 at 16:12
@user2906818 neither, a pointer is a distinct value to the thing it points to. At that point it is an invalid pointer-to-derived that is implicitly convertible to a valid pointer-to-base. In the body of the constructor it is a valid pointer-to-derived
– Caleth
Nov 16 '18 at 16:50
"The "early binding" rule you describe applies to an object currently being constructed" What do you mean by "early binding"?
– curiousguy
Nov 19 '18 at 21:37
@curiousguy That's how the OP described it, though I've never heard the term before.
– aschepler
Nov 20 '18 at 1:47
@aschepler Early binding means that the function called is selected by on the types of the expressions used, at compile time ("early"); as the OP puts it: "If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer"
– curiousguy
Nov 20 '18 at 2:17
|
show 1 more comment
The rule for virtual calls within a constructor body applies to an object currently being constructed, because that object is not yet considered to be an object of any derived class. (And there's a similar rule for an object currently being destroyed.) It has little to do with "early binding" in the sense of using a compile-time type, such as the syntax ClassName::member_func() forces.
Your code has two different objects d and b, and the constructor of d has entirely finished by the time you get to the p->fun(); line.
In detail:
- The program enters
main. - The object
dis created using the implicitly declared default constructor ofDerived. - The first thing
Derived::Derived()does is create the base class subobject, by calling the default constructorBase::Base(). - The body of
Base::Base()callsfun(). Since we have not yet entered the body of theDerived::Derived()constructor, this virtual lookup invokesBase::fun().
Base::Base()finishes.- The body of
Derived::Derived(), which is empty, executes and finishes. - Back in
main, the objectbis created by passing a pointer todto the constructorBase::Base(Base*). - The body of
Base::Base(Base *p)callsp->fun(). Sincepis a pointer tod, which is already a completely constructed object of typeDerived, this virtual lookup invokesDerived::fun().
Contrast with this slightly different example, where we define a default constructor of Derived to pass this (implicitly converted to Base*) to the constructor for the Base subobject. (This is valid, though could be risky if the pointer were used in other ways, such as in an initializer for a base or member of Base.)
#include <iostream>
using std::cout;
using std::endl;
class Base
{
public:
Base(){
fun();
}
Base(Base *p)
{
p->fun();
}
virtual void fun()
{
cout<<"In Base"<<endl;
}
};
class Derived
{
public:
Derived() : Base(this) {}
virtual void fun() override
{
cout << "In Derived" << endl;
}
};
int main()
{
Derived d;
}
This program will print just "In Base", since now in Base::Base(Base *p), p does point at the same object which is currently being constructed.
The rule for virtual calls within a constructor body applies to an object currently being constructed, because that object is not yet considered to be an object of any derived class. (And there's a similar rule for an object currently being destroyed.) It has little to do with "early binding" in the sense of using a compile-time type, such as the syntax ClassName::member_func() forces.
Your code has two different objects d and b, and the constructor of d has entirely finished by the time you get to the p->fun(); line.
In detail:
- The program enters
main. - The object
dis created using the implicitly declared default constructor ofDerived. - The first thing
Derived::Derived()does is create the base class subobject, by calling the default constructorBase::Base(). - The body of
Base::Base()callsfun(). Since we have not yet entered the body of theDerived::Derived()constructor, this virtual lookup invokesBase::fun().
Base::Base()finishes.- The body of
Derived::Derived(), which is empty, executes and finishes. - Back in
main, the objectbis created by passing a pointer todto the constructorBase::Base(Base*). - The body of
Base::Base(Base *p)callsp->fun(). Sincepis a pointer tod, which is already a completely constructed object of typeDerived, this virtual lookup invokesDerived::fun().
Contrast with this slightly different example, where we define a default constructor of Derived to pass this (implicitly converted to Base*) to the constructor for the Base subobject. (This is valid, though could be risky if the pointer were used in other ways, such as in an initializer for a base or member of Base.)
#include <iostream>
using std::cout;
using std::endl;
class Base
{
public:
Base(){
fun();
}
Base(Base *p)
{
p->fun();
}
virtual void fun()
{
cout<<"In Base"<<endl;
}
};
class Derived
{
public:
Derived() : Base(this) {}
virtual void fun() override
{
cout << "In Derived" << endl;
}
};
int main()
{
Derived d;
}
This program will print just "In Base", since now in Base::Base(Base *p), p does point at the same object which is currently being constructed.
edited Nov 24 '18 at 19:23
answered Nov 16 '18 at 15:29
aschepleraschepler
53.7k580131
53.7k580131
@aschelper, very nice explanation. As per your last statement "this" which is sent to base class constructor has the value of derived object or base object?
– user2906818
Nov 16 '18 at 16:12
@user2906818 neither, a pointer is a distinct value to the thing it points to. At that point it is an invalid pointer-to-derived that is implicitly convertible to a valid pointer-to-base. In the body of the constructor it is a valid pointer-to-derived
– Caleth
Nov 16 '18 at 16:50
"The "early binding" rule you describe applies to an object currently being constructed" What do you mean by "early binding"?
– curiousguy
Nov 19 '18 at 21:37
@curiousguy That's how the OP described it, though I've never heard the term before.
– aschepler
Nov 20 '18 at 1:47
@aschepler Early binding means that the function called is selected by on the types of the expressions used, at compile time ("early"); as the OP puts it: "If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer"
– curiousguy
Nov 20 '18 at 2:17
|
show 1 more comment
@aschelper, very nice explanation. As per your last statement "this" which is sent to base class constructor has the value of derived object or base object?
– user2906818
Nov 16 '18 at 16:12
@user2906818 neither, a pointer is a distinct value to the thing it points to. At that point it is an invalid pointer-to-derived that is implicitly convertible to a valid pointer-to-base. In the body of the constructor it is a valid pointer-to-derived
– Caleth
Nov 16 '18 at 16:50
"The "early binding" rule you describe applies to an object currently being constructed" What do you mean by "early binding"?
– curiousguy
Nov 19 '18 at 21:37
@curiousguy That's how the OP described it, though I've never heard the term before.
– aschepler
Nov 20 '18 at 1:47
@aschepler Early binding means that the function called is selected by on the types of the expressions used, at compile time ("early"); as the OP puts it: "If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer"
– curiousguy
Nov 20 '18 at 2:17
@aschelper, very nice explanation. As per your last statement "this" which is sent to base class constructor has the value of derived object or base object?
– user2906818
Nov 16 '18 at 16:12
@aschelper, very nice explanation. As per your last statement "this" which is sent to base class constructor has the value of derived object or base object?
– user2906818
Nov 16 '18 at 16:12
@user2906818 neither, a pointer is a distinct value to the thing it points to. At that point it is an invalid pointer-to-derived that is implicitly convertible to a valid pointer-to-base. In the body of the constructor it is a valid pointer-to-derived
– Caleth
Nov 16 '18 at 16:50
@user2906818 neither, a pointer is a distinct value to the thing it points to. At that point it is an invalid pointer-to-derived that is implicitly convertible to a valid pointer-to-base. In the body of the constructor it is a valid pointer-to-derived
– Caleth
Nov 16 '18 at 16:50
"The "early binding" rule you describe applies to an object currently being constructed" What do you mean by "early binding"?
– curiousguy
Nov 19 '18 at 21:37
"The "early binding" rule you describe applies to an object currently being constructed" What do you mean by "early binding"?
– curiousguy
Nov 19 '18 at 21:37
@curiousguy That's how the OP described it, though I've never heard the term before.
– aschepler
Nov 20 '18 at 1:47
@curiousguy That's how the OP described it, though I've never heard the term before.
– aschepler
Nov 20 '18 at 1:47
@aschepler Early binding means that the function called is selected by on the types of the expressions used, at compile time ("early"); as the OP puts it: "If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer"
– curiousguy
Nov 20 '18 at 2:17
@aschepler Early binding means that the function called is selected by on the types of the expressions used, at compile time ("early"); as the OP puts it: "If early binding is used the selection of the virtual function should be based on the type of the pointer (which is Base * here) but not the content of the pointer"
– curiousguy
Nov 20 '18 at 2:17
|
show 1 more comment
The reason is that C++ classes are constructed from Base classes to derived classes and virtual call table of the complete object is created when the object creation process is completed. Therefore, the base class function is called in the code excerpt above. Unless otherwise mandatory, you should never make virtual function calls in the constructor. Below is an excerpt from Bjarne Stroustrup's C++ Style and Technique FAQ:
In a constructor, the virtual call mechanism is disabled because
overriding from derived classes hasn’t yet happened. Objects are constructed from the base up, “base before derived”.Destruction is done “derived class before base class”, so virtual
functions behave as in constructors: Only the local definitions are used –
and no calls are made to overriding functions to avoid touching the (now
destroyed) derived class part of the object.
Very Nice explanantion. So you mean when we are constructing the derived object for the first time we enter in to the default Base constructor and since the derived object is not yet constructed by that time we go for an early binding and call the Base Virtual function. IN the second case since we have the derived object which is already formed we go for a dynamic binding here and hence call Derived virtual function. Please correct me if my understanding is wrong
– user2906818
Nov 16 '18 at 16:21
yes, this is exactly what I meant to explain.
– Can Yuce
Nov 16 '18 at 16:37
@user2906818 "we go for an early binding" no, we go for a virtual call based on the real type of the object, as always
– curiousguy
Nov 19 '18 at 21:59
"the virtual call mechanism is disabled" no
– curiousguy
Nov 19 '18 at 22:02
@curiousguy Did you check Bjarne Stroustrup's C++ Style and Technique FAQ?
– Can Yuce
Nov 21 '18 at 0:08
|
show 6 more comments
The reason is that C++ classes are constructed from Base classes to derived classes and virtual call table of the complete object is created when the object creation process is completed. Therefore, the base class function is called in the code excerpt above. Unless otherwise mandatory, you should never make virtual function calls in the constructor. Below is an excerpt from Bjarne Stroustrup's C++ Style and Technique FAQ:
In a constructor, the virtual call mechanism is disabled because
overriding from derived classes hasn’t yet happened. Objects are constructed from the base up, “base before derived”.Destruction is done “derived class before base class”, so virtual
functions behave as in constructors: Only the local definitions are used –
and no calls are made to overriding functions to avoid touching the (now
destroyed) derived class part of the object.
Very Nice explanantion. So you mean when we are constructing the derived object for the first time we enter in to the default Base constructor and since the derived object is not yet constructed by that time we go for an early binding and call the Base Virtual function. IN the second case since we have the derived object which is already formed we go for a dynamic binding here and hence call Derived virtual function. Please correct me if my understanding is wrong
– user2906818
Nov 16 '18 at 16:21
yes, this is exactly what I meant to explain.
– Can Yuce
Nov 16 '18 at 16:37
@user2906818 "we go for an early binding" no, we go for a virtual call based on the real type of the object, as always
– curiousguy
Nov 19 '18 at 21:59
"the virtual call mechanism is disabled" no
– curiousguy
Nov 19 '18 at 22:02
@curiousguy Did you check Bjarne Stroustrup's C++ Style and Technique FAQ?
– Can Yuce
Nov 21 '18 at 0:08
|
show 6 more comments
The reason is that C++ classes are constructed from Base classes to derived classes and virtual call table of the complete object is created when the object creation process is completed. Therefore, the base class function is called in the code excerpt above. Unless otherwise mandatory, you should never make virtual function calls in the constructor. Below is an excerpt from Bjarne Stroustrup's C++ Style and Technique FAQ:
In a constructor, the virtual call mechanism is disabled because
overriding from derived classes hasn’t yet happened. Objects are constructed from the base up, “base before derived”.Destruction is done “derived class before base class”, so virtual
functions behave as in constructors: Only the local definitions are used –
and no calls are made to overriding functions to avoid touching the (now
destroyed) derived class part of the object.
The reason is that C++ classes are constructed from Base classes to derived classes and virtual call table of the complete object is created when the object creation process is completed. Therefore, the base class function is called in the code excerpt above. Unless otherwise mandatory, you should never make virtual function calls in the constructor. Below is an excerpt from Bjarne Stroustrup's C++ Style and Technique FAQ:
In a constructor, the virtual call mechanism is disabled because
overriding from derived classes hasn’t yet happened. Objects are constructed from the base up, “base before derived”.Destruction is done “derived class before base class”, so virtual
functions behave as in constructors: Only the local definitions are used –
and no calls are made to overriding functions to avoid touching the (now
destroyed) derived class part of the object.
edited Nov 21 '18 at 0:06
answered Nov 16 '18 at 15:29
Can YuceCan Yuce
94
94
Very Nice explanantion. So you mean when we are constructing the derived object for the first time we enter in to the default Base constructor and since the derived object is not yet constructed by that time we go for an early binding and call the Base Virtual function. IN the second case since we have the derived object which is already formed we go for a dynamic binding here and hence call Derived virtual function. Please correct me if my understanding is wrong
– user2906818
Nov 16 '18 at 16:21
yes, this is exactly what I meant to explain.
– Can Yuce
Nov 16 '18 at 16:37
@user2906818 "we go for an early binding" no, we go for a virtual call based on the real type of the object, as always
– curiousguy
Nov 19 '18 at 21:59
"the virtual call mechanism is disabled" no
– curiousguy
Nov 19 '18 at 22:02
@curiousguy Did you check Bjarne Stroustrup's C++ Style and Technique FAQ?
– Can Yuce
Nov 21 '18 at 0:08
|
show 6 more comments
Very Nice explanantion. So you mean when we are constructing the derived object for the first time we enter in to the default Base constructor and since the derived object is not yet constructed by that time we go for an early binding and call the Base Virtual function. IN the second case since we have the derived object which is already formed we go for a dynamic binding here and hence call Derived virtual function. Please correct me if my understanding is wrong
– user2906818
Nov 16 '18 at 16:21
yes, this is exactly what I meant to explain.
– Can Yuce
Nov 16 '18 at 16:37
@user2906818 "we go for an early binding" no, we go for a virtual call based on the real type of the object, as always
– curiousguy
Nov 19 '18 at 21:59
"the virtual call mechanism is disabled" no
– curiousguy
Nov 19 '18 at 22:02
@curiousguy Did you check Bjarne Stroustrup's C++ Style and Technique FAQ?
– Can Yuce
Nov 21 '18 at 0:08
Very Nice explanantion. So you mean when we are constructing the derived object for the first time we enter in to the default Base constructor and since the derived object is not yet constructed by that time we go for an early binding and call the Base Virtual function. IN the second case since we have the derived object which is already formed we go for a dynamic binding here and hence call Derived virtual function. Please correct me if my understanding is wrong
– user2906818
Nov 16 '18 at 16:21
Very Nice explanantion. So you mean when we are constructing the derived object for the first time we enter in to the default Base constructor and since the derived object is not yet constructed by that time we go for an early binding and call the Base Virtual function. IN the second case since we have the derived object which is already formed we go for a dynamic binding here and hence call Derived virtual function. Please correct me if my understanding is wrong
– user2906818
Nov 16 '18 at 16:21
yes, this is exactly what I meant to explain.
– Can Yuce
Nov 16 '18 at 16:37
yes, this is exactly what I meant to explain.
– Can Yuce
Nov 16 '18 at 16:37
@user2906818 "we go for an early binding" no, we go for a virtual call based on the real type of the object, as always
– curiousguy
Nov 19 '18 at 21:59
@user2906818 "we go for an early binding" no, we go for a virtual call based on the real type of the object, as always
– curiousguy
Nov 19 '18 at 21:59
"the virtual call mechanism is disabled" no
– curiousguy
Nov 19 '18 at 22:02
"the virtual call mechanism is disabled" no
– curiousguy
Nov 19 '18 at 22:02
@curiousguy Did you check Bjarne Stroustrup's C++ Style and Technique FAQ?
– Can Yuce
Nov 21 '18 at 0:08
@curiousguy Did you check Bjarne Stroustrup's C++ Style and Technique FAQ?
– Can Yuce
Nov 21 '18 at 0:08
|
show 6 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53340431%2fdynamic-binding-inside-constructor-for-virtual-function-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
"we know that constructor always go for an early binding" wrong
– curiousguy
Nov 24 '18 at 10:38