I have a base class MyBase that contains a pure virtual function:
void PrintStartMessage() = 0
I want each derived class to call it in their constructor
then I put it in base class(MyBase
) constructor
class MyBase
{
public:
virtual void PrintStartMessage() =0;
MyBase()
{
PrintStartMessage();
}
};
class Derived:public MyBase
{
public:
void PrintStartMessage(){
}
};
void main()
{
Derived derived;
}
but I get a linker error.
this is error message :
1>------ Build started: Project: s1, Configuration: Debug Win32 ------
1>Compiling...
1>s1.cpp
1>Linking...
1>s1.obj : error LNK2019: unresolved external symbol "public: virtual void __thiscall MyBase::PrintStartMessage(void)" (?PrintStartMessage@MyBase@@UAEXXZ) referenced in function "public: __thiscall MyBase::MyBase(void)" (??0MyBase@@QAE@XZ)
1>C:\Users\Shmuelian\Documents\Visual Studio 2008\Projects\s1\Debug\s1.exe : fatal error LNK1120: 1 unresolved externals
1>s1 - 2 error(s), 0 warning(s)
I want force to all derived classes to...
A- implement it
B- call it in their constructor
How I must do it?
If PrintStartMessage() was not a pure virtual function but a normal virtual function, the compiler would not complain about it. However you would still have to figure out why the derived version of PrintStartMessage() is not being called.
Since the derived class calls the base class's constructor before its own constructor, the derived class behaves like the base class and therefore calls the base class's function.
The closest you can get to doing something like that is to fully construct your object first and then calling the method after:
Trying to call a pure abstract method from a derived while that object is still being constructed is unsafe. It's like trying to fill gas into a car but that car is still on the assembly line and the gas tank hasn't been put in yet. I mean what the hell do you expect to happen?
You can't do it the way you imagine because you cannot call derived virtual functions from within the base class constructor—the object is not yet of the derived type. But you don't need to do this.
Calling PrintStartMessage after MyBase construction
Let's assume that you want to do something like this:
The desired execution trace would be:
But this is what constructors are for! Just scrap the virtual function and make the constructor of the derived to do the job!
The output is, well, what we would expect:
This doesn't enforce the derived classes to explicitly implement the
PrintStartMessage
functionality though. But on the other hand, think twice whether it is at all necessary, as they otherwise can always provide an empty implementation anyway.Calling PrintStartMessage before MyBase construction
As said above, if you are to call
PrintStartMessage
before theDerived
has been constructor, you cannot accomplish this because there is no yet aDerived
object forPrintStartMessage
to be called upon. It would make no sense to requirePrintStartMessage
to be a non-static member because it would have no access to any of theDerived
data members.A static function with factory function
Alternatively we can make it a static member like so:
A natural question arises of how it will be called?
There are two solution I can see: one is similar to that of @greatwolf, where you have to call it manually. But now, since it is a static member, you can call it before an instance of
MyBase
has been constructed:The output will be
This approach does force all derived classes to implement
PrintStartMessage
. Unfortunately it's only true when we construct them with our factory function... which is a huge downside of this solution.The second solution is to resort to the curiously recurring template pattern (CRTP). By telling
MyBase
the complete object type at compile time it can do the call from within the constructor:The output is as expected, without the need of using a dedicated factory function.
Accessing MyBase from within PrintStartMessage with CRTP
When
MyBase
is executing, its already OK to access its members. We can makePrintStartMessage
be able to access theMyBase
that has called it:The following is also valid and very frequently used, albeit a bit dangerous:
No templates solution—redesign
Yet another option is to redesign your code a little. IMO this one is actually the preferred solution if you absolutely have to call an overridden
PrintStartMessage
from withinMyBase
construction.This proposal is to separate
Derived
fromMyBase
, as follows:You initialize
MyBase
as follows:You shouldn't call a
virtual
function in a constructor. Period. You'll have to find some workaround, like makingPrintStartMessage
non-virtual
and putting the call explicitly in every constructor.I know this is an old question, but I came across the same question while working on my program.
If your goal is to reduce code duplication by having the Base class handle the shared initialization code while requiring the Derived classes to specify the code unique to them in a pure virtual method, this is what I decided on.
The output is:
There are many articles that explain why you should never call virtual functions in constructor and destructor in C++. Take a look here and here for details what happens behind the scene during such calls.
In short, objects are constructed from the base up to the derived. So when you try to call a virtual function from the base class constructor, overriding from derived classes hasn't yet happened because the derived constructors haven't been called yet.