Abstract class and vector issue

I have an abstract class, SceneObject declared as follow:

PHP Code:

---

#ifndef SCENE_OBJECT_H
#define SCENE_OBJECT_H

#include "Application.h"

class SceneObject{

public:
    SceneObject(void);
    virtual ~SceneObject(void);

public:
    virtual void update(Application* app)=0;
    virtual void render(Application* app)=0;
};
#endif // SCENE_OBJECT_H 


---

There are two more that derive from the above, an implementation...

PHP Code:

---

#ifndef GROUP_H
#define GROUP_H

#include <vector>
#include "SceneObject.h"

class Group : public SceneObject{

private:
    std::vector<SceneObject> children;

public:
    Group(void);
    ~Group(void);

public:
    void update(Application* app);
    void render(Application* app);
};
#endif // GROUP_H 


---

... and a supposed more specialized abstract class:

PHP Code:

---

#ifndef ACTOR_H
#define ACTOR_H

#include "SceneObject.h"

class Actor : SceneObject{

public:
    Actor(void);
    ~Actor(void);

public:
    virtual void update(Application* app)=0;
    virtual void render(Application* app)=0;
};
#endif // ACTOR_H 


---

As you can see, Group has a vector of SceneObjects that will eventually contain Groups or Actors.
On compile, the compiler yields

Code:

---

c:\program files\microsoft visual studio 9.0\vc\include\vector(716) : error C2259: 'SceneObject' : cannot instantiate abstract class
        due to following members:
        'void SceneObject::update(Application *)' : is abstract
        c:\documents and settings\alexandre\my documents\visual studio 2008\projects\ocaso\ocaso\sceneobject.h(13) : see declaration of 'SceneObject::update'
        'void SceneObject::render(Application *)' : is abstract
        c:\documents and settings\alexandre\my documents\visual studio 2008\projects\ocaso\ocaso\sceneobject.h(14) : see declaration of 'SceneObject::render'
        c:\documents and settings\alexandre\my documents\visual studio 2008\projects\ocaso\ocaso\group.h(10) : see reference to class template instantiation 'std::vector<_Ty>' being compiled
        with
        [
            _Ty=SceneObject
        ]

---

Any help is welcome.

As your SceneObject is an abstract class the compiler cannot create a vector of them in the line std::vector<SceneObject> children;

What you need is
std::vector<SceneObject *> children;

Even if your base class wasn't abstract, the original vector would still not have worked as any derived classes of SceneObject added to the vector would have been 'sliced' (All extra information declared in the derived object would be lost as each would be up-converted to SceneObject)

So I'll be getting a pointer to SceneObject with the possibility to down-cast it...

I think I'll probably run into more problems but it's fine.

Thank you!

You don't need to downcast if you're only using the overridden update and render functions.

Code:

---

children[i]->update(...);

---

This will call the correct overridden function for the derived class.

I assume the code for Group will of the form...

Code:

---

void Group::render(Application* app)
{
        std::vector<SceneObject *>::iterator itr = children.begin();

        while (itr != children.end())
        {
                (*itr)->render(app);
                ++itr;
        }
}

---

Also note that you've got class Actor deriving privately from SceneObject, so it can't be pointed to by a SceneObject pointer. You probably want public derivation.

Quote:

---

Originally Posted by JohnW@Wessex

You don't need to downcast if you're only using the overridden update and render functions.

---

I'm aware, thanks :)

Quote:

---

Originally Posted by Graham

Also note that you've got class Actor deriving privately from SceneObject, so it can't be pointed to by a SceneObject pointer. You probably want public derivation.

---

I don't see what you mean by that...

Code:

---

class Actor : SceneObject{

---

classes derive privately by default, so the above is equivalent to

Code:

---

class Actor : private SceneObject{

---

Private derivation is not visible outside of the (derived) class, so external code cannot assign a pointer to Actor to a pointer to SceneObject, therefore, you can't store an actor in your vector<SceneObject*>.

Oh, I didn't know about that.

Thanks for the note, you've probably saved me some headaches.

EDIT:

I've applied the suggested modifications, you guys told me, but I've another problem now. the compilation is successful but when linking...

Code:

---

Actor.obj : error LNK2019: unresolved external symbol "public: virtual __thiscall SceneObject::~SceneObject(void)" (??1SceneObject@@UAE@XZ) referenced in function "public: virtual __thiscall Actor::~Actor(void)" (??1Actor@@UAE@XZ)
Group.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall SceneObject::~SceneObject(void)" (??1SceneObject@@UAE@XZ)
SceneObject.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall SceneObject::~SceneObject(void)" (??1SceneObject@@UAE@XZ)

---

Note: The Group class declaration misses a ': public SceneObject'; my code is corrected.

Looks like you never created a definition for the SceneObject destructor. As SceneObject is abstract I'm pretty sure you can define it as a pure virtual, as long as a destructor is defined in the derived class.

You can declare a destructor as pure virtual, but you have to give it a definition - you can't get away with not defining a destructor that you've declared - that's one function that will definitely be called. In this case, however, I would suggest that simple inline blank destructor is all that's needed:

Code:

---

class SceneObject
{
public:
    virtual ~SceneObject() {}
//...
};

---

Then subclasses can decide either to define their own destructor or not.

Thanks guys!

Subclass doesnt need an destructor if it has got no business...

BUt its always better to give one destructor even if its a blank..

like ~SubClass(){};

Quote:

---

BUt its always better to give one destructor even if its a blank..

like ~SubClass(){};

---

What's your rationale for that?

It just gives out an impression that class creator has not forgotten to implement destructor.. He has not missed it...

If I dont see a destructor I would wonder whether he forgot to implement one...???