Thread: Virtual Method question...

I suspect your example code is not your real code, since it won't compile.

I modified it into this [using STL classes, since I don't know that your List class actually does], and it works fine:

Code:

#include <iostream>
#include <list>

class Base
{
public:
  virtual void doSomething() { std::cout << "Base" << std::endl; }
};

class Derived : public Base
{
public:
  virtual void doSomething() { std::cout << "Derived" << std::endl; }
};

int main()
{
     Base* p;  
     std::list<Base*>  lst;
     lst.push_back(new Derived()); 
     p = lst.back();
     p->doSomething();   // For some reason this is calling Base::doSomething()

     return 0;  
}

--
Mats

Okay, thanks,

Code:

   RTSConnection* conn = RTSConnection::getServerConnection();
   for (U32 i = 0; i < mObjectList.size(); i++)
   {
      SceneObject* unit = listOfSceneObjects[i]; 

      if ( unit->getTeam() == conn->getTeam() )    // unit->getTeam() is calling virtual S32 SceneObject::getTeam() for some reason, meanwhile
                                                                            //  listOfSceneObjects[i] is a pointer to a RTSUnit, and an RTSUnit overrides getTeam().  Also note RTSUnit                    
                                                                            //derives (eventually) from SceneObject...  
         continue;

       etc....

I don't think that's any more clear, but it is what you asked for :P

Well, of course, we'd need to see the REST of the code so that it can be compiled. Your simple example isn't the same as "the minimal complete example that compiles and demonstrates the problem".

In your process to whittle down your code into that, you may well find the actual problem.

Certainly, there's nothing in your code-snippet that is directly wrong, as far as I can see. But it's also very different from the code you originally posted, and the problem is very likely in a different portion of code.

--
Mats

My gut tells me it has something to do with this:

Code:

void addObject(SceneObject* unit)
{
      listOfSceneObjects.add(unit);
}

that shows how the listOfSceneObjects gets populated in the first place. listOfSceneObjects is actually a SimSet which is a Set of SimObjects and everything else in the code derives from SimObject.

So if I add an RTSUnit* unit;
like this:
addObject(unit);

Does this somehow strip the v-table out of unit or what lol


EDIT: I cannot provide compileable code as it is 100's of thousands of lines long. But what I have shown is really all that is going on. I just don't understand it

I'm assuming RTSUnit is a derived class based on SceneObject (or it shouldn't compile). I don't see anything wrong with that code either.

--
Mats

Yeah, that would be an ugly hack and not the right solution.

You may want to check your vtable in the debugger [most debuggers will at least show the address of the vtable].

--
Mats

If listOfSceneObjects is a Set<SimObject*> (why!?) and SceneObject derives from SimObject, why does this line compile?

Code:

SceneObject* unit = listOfSceneObjects[i];

that shows how the listOfSceneObjects gets populated in the first place. listOfSceneObjects is actually a SimSet which is a Set of SimObjects and everything else in the code derives from SimObject.

Is listOfSceneObjects actually a Set of (smart) pointers to SimObjects? If it really stored SimObjects instead of pointers (or references, but that's rare for a container), type slicing occurs, so all you have are SimObjects with the subtype information lost.

Delving deeper into SimSet ( what listOfSimObjects is )

Code:

template<class T> inline void VectorPtr<T>::push_back(const T& x)
{
   Parent::push_back((Parent::const_reference)x);
}

Code:

template<class T> inline void Vector<T>::push_back(const T& x)
{
   increment();
   mArray[mElementCount - 1] = x;
}

So it appears this is the result of type slicing after all. thanks laserlight!

Ok, so is it this cast?

Code:

Parent::push_back((Parent::const_reference)x);