Page 1 of 1
Basic C++ question
Posted: Sat Apr 14, 2007 4:23 pm
by spopo
Hello everyone, when i realised that one single .cpp file won't work for a game, i started to make an enemy class like this :
Code: Select all
Enemy.h
#ifndef Enemy_h
#define Enemy_h
class Enemy {
irr::scene::IAnimatedMeshSceneNode Node;
public:
void setNode (irr::scene::IAnimatedMeshSceneNode *node);
irr::scene::IAnimatedMeshSceneNode getNode(void);
};
#endif
Enemy.cpp
#include "Enemy.h"
void Enemy::setNode(irr::scene::IAnimatedMeshSceneNode *node)
{
Node = node;
}
irr::scene::IAnimatedMeshSceneNode Enemy::getNode(void)
{
return Node;
}
Main.cpp
#include <irrlicht.h>
#include <windows.h>
#include <irrKlang.h>
#include <stdlib.h>
#include <time.h>
#include "Enemy.h"
#pragma comment(lib, "irrKlang.lib")
#pragma comment(lib, "Irrlicht.lib")
using namespace irr;
using namespace audio;
And the problem is, that enemy.h and enemy.cpp cannot use libraries, that is included in the main.cpp. So my question is, how to easily solve this problem, to avoid multiple header inclusion and so on..
And also, should i return *IAnimatedMeshSceneNode or just IAnimatedMeshSceneNode?
Posted: Sat Apr 14, 2007 6:30 pm
by vitek
And the problem is, that enemy.h and enemy.cpp cannot use libraries, that is included in the main.cpp.
Don't worry about the lib pragma things. Those only need to be done once for your project. The includes, well you can just put them into your Enemy.h.
should i return *IAnimatedMeshSceneNode or just IAnimatedMeshSceneNode
You should return
IAnimatedMeshSceneNode*. The type of
Node should be changed to
IAnimatedMeshSceneNode* also. This is because you cannot instantiate the abstract class
IAnimatedMeshSceneNode. If you attempt to you should get a compiler error.
You should also be defining a constructor that initializes
Node to some known value [usually NULL]. Your
setNode method should call
drop() on the old
Node if it is valid, and then call
grab() on the new node. You should add a destructor that calls
drop() if the node is valid. This stuff is necessary to be sure that the enemy can't accidentally end up with a pointer to a node that has been destroyed.
Travis
Posted: Sat Apr 14, 2007 7:50 pm
by spopo
Thanks for your detailed reply, and i want to ask another thing. Right now it's like this :
Code: Select all
Enemy.h
#ifndef Enemy_h
#define Enemy_h
#include <irrlicht.h>
class Enemy {
irr::scene::IAnimatedMeshSceneNode *Node;
public:
void setNode (irr::scene::IAnimatedMeshSceneNode *node);
irr::scene::IAnimatedMeshSceneNode* getNode(void);
};
#endif
It compiles fine, however, i included irrlicht.h in the main.cpp, so isn't it multi inclusion? Sorry for these noob questions, it's just the first times i write classes in separate files.
Posted: Sat Apr 14, 2007 8:02 pm
by agi_shi
spopo wrote:Thanks for your detailed reply, and i want to ask another thing. Right now it's like this :
Code: Select all
Enemy.h
#ifndef Enemy_h
#define Enemy_h
#include <irrlicht.h>
class Enemy {
irr::scene::IAnimatedMeshSceneNode *Node;
public:
void setNode (irr::scene::IAnimatedMeshSceneNode *node);
irr::scene::IAnimatedMeshSceneNode* getNode(void);
};
#endif
It compiles fine, however, i included irrlicht.h in the main.cpp, so isn't it multi inclusion? Sorry for these noob questions, it's just the first times i write classes in separate files.
No.
It'll find the inclusion guard from the previous inclusion, and the file (if guarded right) will be "skipped".
It's good to include everything where you need it though, even if it'll end up already being included, to avoid confusion.
Posted: Sat Apr 14, 2007 10:32 pm
by sudi
actually not.....u should not include stuff in files where it is not needed.
for example when u write an interface for all ur objects in the game.
and this object has a pointer to a physics object youd should do the following.
#IObject.h#
class IPhysicsObject;
class IObject
{
public:
void setPhysicsObject(PhysicsObject* obj)
{
m_obj = obj;
}
IPhysicsObject* getPhysicsObject(void)
{
return m_obj;
}
PhysicsObject* m_obj;
};
that way u don't have to recompile the cpp files that only include and use IObject when u change the definition of PhysicsObject.
in smal projects this doesn't matter but when u have a butload of cpp files this can keep the compilation time low.