Basic C++ question

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
Post Reply
spopo
Posts: 33
Joined: Wed Mar 28, 2007 1:46 pm

Basic C++ question

Post 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?
vitek
Bug Slayer
Posts: 3919
Joined: Mon Jan 16, 2006 10:52 am
Location: Corvallis, OR

Post 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
spopo
Posts: 33
Joined: Wed Mar 28, 2007 1:46 pm

Post 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.
agi_shi
Posts: 122
Joined: Mon Feb 26, 2007 12:46 am

Post 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.
sudi
Posts: 1686
Joined: Fri Aug 26, 2005 8:38 pm

Post 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.
We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by renovation:tinkering,improving,planting flower beds.
Post Reply