Pure virtual base class question
-
So class _base is a pure virtual class. Class _child derives from it and implements the functions. The code creates an instance of _base and uses it. Question. It seems that when an instance of a pure virtual base class is created, an instance of its child is in fact created. Is this so? An observation. VS finds it impossible to debug step into any functions of the _child instance. Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate? While I know C++ well, I have never come across this before, and I would never code this way, it looks ugly, is unclear, and makes debugging impossible. (I work mostly in the kernel in C)
============================== Nothing to say.
-
So class _base is a pure virtual class. Class _child derives from it and implements the functions. The code creates an instance of _base and uses it. Question. It seems that when an instance of a pure virtual base class is created, an instance of its child is in fact created. Is this so? An observation. VS finds it impossible to debug step into any functions of the _child instance. Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate? While I know C++ well, I have never come across this before, and I would never code this way, it looks ugly, is unclear, and makes debugging impossible. (I work mostly in the kernel in C)
============================== Nothing to say.
Eric__V wrote:
instance of _base
I doubt on the term instance in case of pure virtual class.You can't create an instance of a class if it have a pure virtual function.May be the code is declaring the pointer of base class and assigning the instance of derived class.Like, _base *pbase = new basederive();
Eric__V wrote:
Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate?
This will be done with help of virtual pointer table.There are lot of articles in code project on this.Start from this link, ATL Under the Hood - Part 2
-
Eric__V wrote:
instance of _base
I doubt on the term instance in case of pure virtual class.You can't create an instance of a class if it have a pure virtual function.May be the code is declaring the pointer of base class and assigning the instance of derived class.Like, _base *pbase = new basederive();
Eric__V wrote:
Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate?
This will be done with help of virtual pointer table.There are lot of articles in code project on this.Start from this link, ATL Under the Hood - Part 2
-
Yeah, I just dug a bit dfeeper and indeed, it is newed off the derived class. I still want to know why VS cant step into the damn code though. Its really pissing me off.
============================== Nothing to say.
-
So class _base is a pure virtual class. Class _child derives from it and implements the functions. The code creates an instance of _base and uses it. Question. It seems that when an instance of a pure virtual base class is created, an instance of its child is in fact created. Is this so? An observation. VS finds it impossible to debug step into any functions of the _child instance. Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate? While I know C++ well, I have never come across this before, and I would never code this way, it looks ugly, is unclear, and makes debugging impossible. (I work mostly in the kernel in C)
============================== Nothing to say.
Eric__V wrote:
It seems that when an instance of a pure virtual base class is created, an instance of its child is in fact created.
When an instance of the derived class is created then you have also an instance of the base class (because 'derived' is 'base'): you cannot instantiate an abstract class.
Eric__V wrote:
An observation. VS finds it impossible to debug step into any functions of the _child instance.
Visual Studio debugger should be able to do that (the debugger is one of the amazing features of Visual Studio, in my opinion).
Eric__V wrote:
Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate?
Choosing the appropriate derived class to instantiate (to get base class functionality) is up to you.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
So class _base is a pure virtual class. Class _child derives from it and implements the functions. The code creates an instance of _base and uses it. Question. It seems that when an instance of a pure virtual base class is created, an instance of its child is in fact created. Is this so? An observation. VS finds it impossible to debug step into any functions of the _child instance. Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate? While I know C++ well, I have never come across this before, and I would never code this way, it looks ugly, is unclear, and makes debugging impossible. (I work mostly in the kernel in C)
============================== Nothing to say.
Eric__V wrote:
The code creates an instance of _base and uses it.
Maybe I do not understand the question correctly. :confused: You cannot create an instance of the base class if it contains pure virtual member functions.
class Onion
{
public:
virtual void f( ) = 0;
};class Tata : public Onion
{
virtual void f();
};... Onion onion; // will generate a compiler error. ...
Watched code never compiles.
-
Eric__V wrote:
The code creates an instance of _base and uses it.
Maybe I do not understand the question correctly. :confused: You cannot create an instance of the base class if it contains pure virtual member functions.
class Onion
{
public:
virtual void f( ) = 0;
};class Tata : public Onion
{
virtual void f();
};... Onion onion; // will generate a compiler error. ...
Watched code never compiles.
Even
Tata tata;
would generate a compiler error... ;P
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Even
Tata tata;
would generate a compiler error... ;P
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]CPallini wrote:
would generate a compiler error...
No, that does not generate a compiler error. But maybe you're laughing at something else ? :confused:
Watched code never compiles.
-
Eric__V wrote:
instance of _base
I doubt on the term instance in case of pure virtual class.You can't create an instance of a class if it have a pure virtual function.May be the code is declaring the pointer of base class and assigning the instance of derived class.Like, _base *pbase = new basederive();
Eric__V wrote:
Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate?
This will be done with help of virtual pointer table.There are lot of articles in code project on this.Start from this link, ATL Under the Hood - Part 2
Eric__V wrote:
How does the compiler know which one to instantiate?
venkatmakam wrote:
This will be done with help of virtual pointer table.
No, instantiation is always explicitly written in code, and the proper virtual table is selected on instantiation.
-
CPallini wrote:
would generate a compiler error...
No, that does not generate a compiler error. But maybe you're laughing at something else ? :confused:
Watched code never compiles.
Did you try it? In your code the function implementation is missing. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Did you try it? In your code the function implementation is missing. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
I think he meant that it won‘t be a compiler problem, but rather something the linker will stumble upon.
Good point. However I don't know if it is what he meant.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Good point. However I don't know if it is what he meant.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Eric__V wrote:
I still want to know why VS cant step into the damn code though.
Have you compiled and built it in Debug mode?
The best things in life are not things.
Yeah, its running on a remote machine, so I am doing an 'attach to process' in VS. pdbs are on the remote machine with the exes and dlls (best way to handle symbols for VS IMO). OS symbols are stored on the dev machie locally and off Microsofts symsrv. But weird, just cant step into the code. Its not even complaining about lack of source code and offering the view assembler approach. Cant really devote time to finding out why its not doing it, too much real work to do else where. :)
============================== Nothing to say.
-
Eric__V wrote:
It seems that when an instance of a pure virtual base class is created, an instance of its child is in fact created.
When an instance of the derived class is created then you have also an instance of the base class (because 'derived' is 'base'): you cannot instantiate an abstract class.
Eric__V wrote:
An observation. VS finds it impossible to debug step into any functions of the _child instance.
Visual Studio debugger should be able to do that (the debugger is one of the amazing features of Visual Studio, in my opinion).
Eric__V wrote:
Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate?
Choosing the appropriate derived class to instantiate (to get base class functionality) is up to you.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]I dug a bit deeper and in fact the _base pointer instance is new'ed as the sub classes. And now I saw that, I remember from about 12 years ago, that I have seen this before. Spent the last 10 years pretty much 100% in the kernel so I guess I got a bit rusty with the old C++ inheritance game. :)
============================== Nothing to say.
-
Eric__V wrote:
The code creates an instance of _base and uses it.
Maybe I do not understand the question correctly. :confused: You cannot create an instance of the base class if it contains pure virtual member functions.
class Onion
{
public:
virtual void f( ) = 0;
};class Tata : public Onion
{
virtual void f();
};... Onion onion; // will generate a compiler error. ...
Watched code never compiles.
-
Yeah, its running on a remote machine, so I am doing an 'attach to process' in VS. pdbs are on the remote machine with the exes and dlls (best way to handle symbols for VS IMO). OS symbols are stored on the dev machie locally and off Microsofts symsrv. But weird, just cant step into the code. Its not even complaining about lack of source code and offering the view assembler approach. Cant really devote time to finding out why its not doing it, too much real work to do else where. :)
============================== Nothing to say.
-
Did you try it? In your code the function implementation is missing. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]It is never referenced, so the linker will not report it. ;P yeah, good catch!
Watched code never compiles.
-
But Onion* pOnion = new Tata is OK, and this is what the code was actually doing when I looked a bit deeper. Doesnt explain VS though not debugging into the funcs. :(
============================== Nothing to say.
Have you still not solved that issue? VS should step into virtual funcs - I do it every day, using VS 2003, and now that I switched it to VS2010 it works just as well. Apart from your debugging a remote program - I haven't done that myself, the only thing I can think of is that your code does something different than you think it should. but without seeing the code we can't say. Can you extract the relavnt bits of your code (i. e. the declaration of the virtual func in the base class and how you overrode it in your derived class) and post it?
-
Have you still not solved that issue? VS should step into virtual funcs - I do it every day, using VS 2003, and now that I switched it to VS2010 it works just as well. Apart from your debugging a remote program - I haven't done that myself, the only thing I can think of is that your code does something different than you think it should. but without seeing the code we can't say. Can you extract the relavnt bits of your code (i. e. the declaration of the virtual func in the base class and how you overrode it in your derived class) and post it?