1

I was trying below code:

In which I am calling opengascap() of car class with car* pointer which is pointing to a object of nuclear** class but it is giving nuclear*** function of the object that is being pointed to. My question is why its giving output "fire" although the function name doesn't even exist in the nuclearsubmarine class.

  #include <iostream>

  using namespace std;

  class Vehicle 
  {
      public:
      virtual ~Vehicle() { }
      virtual void startEngine() = 0;
  };

  class Car : public Vehicle 
  {
  public:
      virtual void startEngine()
      {
          cout<<"start car";
      }
      virtual void openGasCap()
      {
      cout<<"open";
      }
  };

  class NuclearSubmarine : public Vehicle 
  {
      public:
      virtual void startEngine()
      {
          cout<<"start ship";
      }
      virtual void fireNuclearMissle()
      {
          cout<<"fire";
      }
  };

 int main()
 {
     Car   car;
     Car*  carPtr = &car;
     NuclearSubmarine  sub;
     NuclearSubmarine* subPtr = &sub;
     carPtr=(Car*)subPtr;
     // This last line would have caused carPtr to point to sub !
     carPtr->openGasCap();  // This might call fireNuclearMissle()!
     return 0;
 }

Ouput: fire

SingerOfTheFall
  • 29,228
  • 8
  • 68
  • 105
cexplorer
  • 549
  • 5
  • 13
  • You should have a look at http://stackoverflow.com/questions/28002/regular-cast-vs-static-cast-vs-dynamic-cast. C-style casts can result in undefined behaviour, and you should try to avoid them whenever possible. – Zeta Aug 01 '12 at 06:19

1 Answers1

4

You're pointing to an object of type NuclearSubmarine with a pointer to type Car. You can't do that, because these types are unrelated.

This error invokes undefined behaviour, which causes your program to behave in an unpredictable way.


If you're interested in why this happens, have a read on how virtual functions are implemented internally: Virtual method table. This will make things clear for you.


In reply to the comment:

That's right. Vehicle instances all have an internal pointer that points to a vtable which looks something like this:

0: Vehicle::~Vehicle
1: Vehicle::StartEngine                   // this is a null pointer

Car instances have their vptr point to a vtable which looks something like this:

0:Vehicle::~Vehicle                       // this one didn't get overridden
1:Car::startEngine
2:Car::openGasTrap

NuclearSubmarine's vtable looks like this:

0:Vehicle::~Vehicle                       // this one didn't get overridden
1:NuclearSubmarine::startEngine
2:NuclearEngine::fireNuclearMissile.

If you have this,

Vehicle* v = new Car();
v->startEngine();

it gets compiled into something like this (pseudocode ahead):

Vehicle* v = new Car();
// OK, v is a Vehicle and startEngine is a Vehicle's virtual function of index 1
// let's call it!
StartEngineFunc* f = v.VPTR[1]; // look up the vtable using the object's virtual pointer
CallMethod(v, f);

The virtual pointer refers the function lookup into the correct vtable w/r/t the object's actual runtime type.

This allows you to call methods of derived classes via pointers to base classes, since derived classes will have their virtual table (the first part of it) corresponding to its parent class.

However, if two classes are not related by a parent-child relationship, their virtual tables will have different meaning. That's what happens in your case.

(Note that while the vtable mechanism is an implementation detail - it's very common in compilers, but it isn't enforced in any way and compilers are free to implement it differently - so you shouldn't count on that in your programs.)

Kos
  • 70,399
  • 25
  • 169
  • 233
  • Hi Kos my ques is diff I know I should not do that but just curious to know why this is happening. Is it happening because it is invoking through offset address mechanism? means lets say it sets offset=2 in this case since opencase is second fun and then it is adding this to vptr of nuclear where nuclearmissile fun is placed. is it so? – cexplorer Aug 01 '12 at 06:20
  • Thank you very much Kos fr such a nice exp!!! But i was thinking how the order of lookup is being decided. is it order of declaring in the class? but when i changed the order of startengine and nuclear*** it still gave "fire". can you explain that also? – cexplorer Aug 01 '12 at 07:13
  • Because the base class' methods always go first in the same order as in the base class. Try adding another new virtual function in submarine and then swap their places - this may make a difference (or not). – Kos Aug 01 '12 at 09:13
  • Yes Kos you were right!!! I added a third "fun" and swapped the position of third and nuclear. Now the base at 1, "fun" at 2 and "nuclear**" at 3. and it now gave output of "fun". Thank you so much!!! – cexplorer Aug 01 '12 at 10:35