Keyword 'virtual' and interface class definitions - compiler tolerance

Hi there,

I have a fairly straightforward question. Check out the class below:

Code:

---

class winInterface
{
public:
        virtual ~winInterface();
        virtual HWND createWindow(HINSTANCE hInstance, WINPROC _winproc,
                        WCHAR* szTitle, WCHAR* szWindowClass, int nCmdShow) = 0;

        HINSTANCE hInstance;
        HWND hwnd;
        WINPROC _winProc;
        WCHAR szTitle[MAX_LOADSTRING];
        WCHAR szWindowClass[MAX_LOADSTRING];
};

---

All this works fine. Provides a little interface to a derived class in a DLL which sets up a window (hence the pure virtual function). I noticed though I had terrible trouble yesterday with a linker error when I did not use the virtual keyword.

One way I got around this was to put a small definition of the function in the shared interface header file, which was to be over-rided later. Now I find since I've upped my game a bit and included the virtual keyword (like I was supposed to) it's no longer an issue.

None of this is a problem but... does that mean that provided you use the virtual keyword the compiler wont even ask for a function definition anywhere and will just tolerate that? Even though it has no access to the header file specific to the DLL where the function is actually defined? (I've checked that it doesn't).

I just sorta need to know...for some reason :p

Thanks :)

Quote:

---

does that mean that provided you use the virtual keyword the compiler wont even ask for a function definition anywhere and will just tolerate that?

---

"pure virtual" is where you have both 'virtual' and '= 0'. The '= 0' part tells the compiler that you won't be supplying a definition for that method in that class. Therefore the derived class must supply a definition or the program will not compile.

"virtual" is where you have 'virtual' but not '= 0'. In that case you need to supply a definition and the derived class can either override it or not.

Virtual functions are used for runtime polymorphism, which allows a pointer or reference to the base class to be used to call functions from a derived class.

Code:

---

#include <iostream>
#include <vector>
using std::cout;
 
class Animal {
public:
  Animal()            { cout << "Animal::Animal\n"; }
  virtual ~Animal()    { cout << "Animal::~Animal\n"; }
  virtual void speak() = 0;
};
 
class Dog : public Animal {
public:
  Dog()        { cout << "Dog::Dog\n"; }
  ~Dog()      { cout << "Dog::~Dog\n"; }
  void speak() { cout << "Bark\n"; }
};
 
class Cat : public Animal {
public:
  Cat()        { cout << "Cat::Cat\n"; }
  ~Cat()      { cout << "Cat::~Cat\n"; }
  void speak() { cout << "Meow\n"; }
};
 
int main() {
  // Store pointers to the base class.
  std::vector<Animal*> animals;
  animals.push_back(new Dog()); cout << '\n';
  animals.push_back(new Cat()); cout << '\n';
  animals.push_back(new Cat()); cout << '\n';
  animals.push_back(new Dog()); cout << '\n';
 
  // Dynamically dispatch the speak method.
  // Even though 'a' is a pointer to the base class
  // it is able to be used to call the derived classes' methods.
  // This is due to the VTABLE mechanism (lookup "C++ vtable").
  for (const auto a: animals) a->speak();
  cout << '\n';
 
  // Call all of the destructors including the derived classes' dtors
  // due to the magic of the base class's virtual dtor.
  // Note that this is a little different than regular virtual methods
  // since the derived class dtor obviously doesn't have the same name
  // as the base class dtor, and after the derived class's dtor has run,
  // the base class dtor is executed as well.
  for (auto a: animals) { delete a; cout << '\n'; }
}

---

Nice to see you again John thanks for taking the time to write the reply. I've read right through it and I'm pleased to say I actually understood it! Thanks :)