Quote:Original post by cache_hitFor example, to obtain base class functionality you have to explicitly call the base class version of a function. Like say you implement some method foo() and you override that in a derived class. The derived class then has to remember to call the base foo() in order to gain its functionality. But where do you call it? At the beginning? Somewhere in the middle? At the end? The answer: it depends what you want to do.
Well that is not the way to use function overloading in my opinion. If you need to reimplement a function in a derived class then you either want to replace the whole implementation or your base implementation lacks things. If you only need added functionality and still rely on the base implementation you would something like this:
class Base{public: Base(); virtual ~Base(); void Foo () { // do something FooInternal(); }protected: virtual void FooInternal() { // empty base implementation }};
Now each derived class can use the base functionality of Foo and still adding functionality in FooInternal which gets called automatically. If you think there are reasons some classes need to call their own stuff before or after Foo executes extend this scheme to:
class Base{public: Base(); virtual ~Base(); void Foo () { FooBeginInternal(); // do something FooEndInternal(); }protected: virtual void FooBeginInternal() { // empty base implementation } virtual void FooEndInternal() { // empty base implementation }};
@original poster
There is no single valid answer to that, as always it depends on your coding style and the remainder of your code an interfaces. But without knowing the design in depth I would suggest (as most others did above) to use the physics and the renderable class as attributes of the entity class. Philosophers might argue that an enty
is a
renderable while others would say the entity from the interface point of view
has a
renderable. To avoid nasty multiple inheritance I would always opt for the
has a way of doing things.
Another classical example is a rag doll class. Its a skinned mesh as well as a physics object. No go one step ahead and think of an instanced skinned mesh class. This is a skinned mesh as well as an instanced mesh as well as a physics object. There is no easy way of reflecting this by using interfaces. The only valid C++ solution in such a case would be to have abstract classes where you can use multiple inheritance savely. But then you would either have to provide duplicated code because the implementing classes must not use multiple inheritance or you have to write helper classes to perform various tasks which are used by the implementing classes.
Anyway, in this way I would use a design like that:
class Transform; // stores access to the transformation attributesclass Renderable; // represents a tri mesh for example, doesn't care about transformations thoughclass PhysicsObject{public: const Transformation& GetTransformation() const;private: Transform m_trans;};class Entity{public: void Update() { if (m_po != 0) { m_po->Update(); m_trans = m_po->getTransformation(); } else { // update transformation by AI or whatever } } const Transformation& GetTransformation() const; const Renderable* getRenderable () const;private: PhysicsObject* m_po; Renderable* m_r; Transformation m_trans;};
In this design you would have a scene graph or a similar structure that stores all of your entites, updates them each frame, and then get their transformation and renderable to render the visual representation of the entity.
------------------------------------I always enjoy being rated up by you ...
