468,463 Members | 2,032 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,463 developers. It's quick & easy.

Logic question...

I am writing a game and I am having a challenge with my combat
function. All I want to do is find out how to group pieces that are in
the same space. There are two sides and all the units that are in the
same space fight. I want to add up the attack factors and defending
factors in the same space then figure out the odds so I can roll
against an odds table. Basically each piece holds its own x and y loc.
Here is what I have right now:

void fight(vector<unit>& at, vector<unit>& dt,
board * b , terrain * trn ){

vector<fightclassfighting;

/* adds attacking units to the fightclass vector if units are in the
same space they are to grouped in the same fight class elemet of
the
vector. */

for(int atu = 0; atu != at.size(); atu++){
if(fighting.size() == 0){
fightclass ft;
ft.addAu(at[atu]);
fighting.push_back(ft);
} else {
for(int lp = 0; lp != fighting.size(); lp++){
if(at[atu].getXloc() != fighting[lp].getX() &&
at[atu].getYloc() != fighting[lp].getY()){
fightclass ft;
ft.addAu(at[atu]);
fighting.push_back(ft);
} else {
fighting[lp].addAu(at[atu]);
}
}
}
}
/* Adds defending units to the fightclass array. If x and y locs are
the same as attacking locations (are in the same space) they are
added to array for combat */

for(int dtu = 0; dtu != dt.size(); dtu++){
for(int lp = 0; lp != fighting.size(); lp++){
if(dt[dtu].getXloc() == fighting[lp].getX() &&
dt[dtu].getYloc() == fighting[lp].getY()){
fighting[lp].addDu(dt[dtu]);
}
}
}

// Combat routine

for(int lp = 0; lp != fighting.size(); lp++){ //handles combat
if(fighting[lp].canfight()){
int df = b->GetSpace(fighting[lp].getX(), fighting[lp].getY());
float odds =
fighting[lp].getAtk()/fighting[lp].getDef();
//gets the defense bonus for the terrain in the space where
//combat takes place
int roll = rand() - trn[df].defend();
//get the die roll modified for terrain
odds = fighting[lp].getAtk() / fighting[lp].getDef();
//gets the attack to defence ratio.
if(odds < .5){
MessageBox(NULL, "Fighting! 1:3", "Info!", MB_OK);
return;
}
if(odds < 1){
MessageBox(NULL, "Fighting! 1:2", "Info!", MB_OK);
return;
}
if(odds < 2){
MessageBox(NULL, "Fighting! 1:1", "Info!", MB_OK);
return;
}
if(odds < 3){
MessageBox(NULL, "Fighting! 2:1", "Info!", MB_OK);
return;
}
if(odds < 4){
MessageBox(NULL, "Fighting! 3:1", "Info!", MB_OK);
return;
}
if(odds < 5){
MessageBox(NULL, "Fighting! 4:1", "Info!", MB_OK);
return;
}
if(odds < 6){
MessageBox(NULL, "Fighting! 5:1", "Info!", MB_OK);
return;
}

}
}
for(int lp = 0; lp != fighting.size(); lp++){
fighting[lp].done();
}
fighting.clear();
}

class fightclass{
/* Fightclass holds two arrays of units. The two arrays represent
units
in the same space elgible for combat. Array at represents the
attacking
forces and dt represents the defending units */
int xl;
int yl;

bool sides2; /* indicates if there are units in both attack and
defend
if there are units in both attack and defend then
combat
is to take place between the opposing sides. */

vector<unit>at; //attack units
vector<unit>dt; //defending units

public:
fightclass();
void addAu(unit au); //adds an addacking unit
void addDu(unit du); //adds a defending unit
int getX(){return xl;} //return the x coord
int getY(){return yl;} //returns the y coord
float getAtk(); //returns the total attack factors for one space
float getDef(); //returns the total defending factors for one space
bool canfight(); //if there are both attacking and defending units
void done(); //clears vectores after the turn

};

fightclass::fightclass(){
xl = 0;
yl = 0;
}

void fightclass::addAu(unit u){
at.push_back(u);
xl = u.getXloc();
yl = u.getYloc();

}

void fightclass::addDu(unit u){

dt.push_back(u);

}

bool fightclass::canfight(){
if(at.size() && dt.size()){
return true;
}else {return false;}
}

float fightclass::getAtk(){
float total;
for(int lp = 0; lp != at.size(); lp++){
total +=at[lp].getAttack();
}
return total;
}

I know the logic is not the best but it is the best I can do. This is
tricky and I am pretty confused. I would like to find some way of
making the logic steps easier. There may be some simple error that I
overlooked or it can be totally screwed up.

Sep 4 '06
73 3674

Nathan Mates wrote:
In article <11*********************@m73g2000cwd.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
I have to do some studying to be able to understand how to make a map
manager work. I feel bad but it confuses me. I will have to do some
studying and try to learn how this works. I know how to use a map and
other standatd containers and I once wrote a simple linked list but I
never realy worked with it much farther. I worte a program simmiliar
to this but it was pretty buggy:

Why write a linked list? std::list<Object*is a linked list, and
is fully debugged already. Use what you've got for free.

Nathan Mates
--
I took some of your advice and did my best to create a map manager and
so far it is working great. It is much easier and less buggy than
anything I could come up with. It was a challenge trying to
conceptualize the object. I didn't use pointers or anything and
creating the map was a challenge but so far the object does everything
I want it to do.

class mapmgt{
int xlen; //map size (max 100)
int ylen;

struct hold{
vector<unit>at; //holds the attackers
vector<unit>dt; //holds the defenders
};
table t; //combat results table
hold h[100][100]; //allows for a map max 100x100.

public:
mapmgt();
mapmgt(int, int); //creates a map size of x and y

void atIn(unit&); //reads in units
void dtIn(unit&);
void fight();
void clear(); //clears the map at the end of the turn

};

mapmgt::mapmgt(int x, int y){
xlen = x;
ylen = y;
if(x 199 || y 99){
MessageBox(NULL, "The map is too big, edit the program!", "Error!",
MB_OK);
}
}

void mapmgt::atIn(unit& u){
int x = u.getXloc();
int y = u.getYloc();
h[x][y].at.push_back(u);

}

void mapmgt::fight(){
for(int lp1 = 0; lp1 != ylen; lp1++){
for(int lp2 = 0; lp2 != xlen; lp2++){
if(h[lp2][lp1].at.size() 0 && h[lp2][lp1].dt.size() 0){
MessageBox(NULL, "There is fighting!", "simulation!", MB_OK);
}
}
}

}

Sep 18 '06 #51
In article <11**********************@h48g2000cwc.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
>I took some of your advice and did my best to create a map manager
and so far it is working great. It is much easier and less buggy
than anything I could come up with. It was a challenge trying to
conceptualize the object. I didn't use pointers or anything and
creating the map was a challenge but so far the object does
everything I want it to do.
Why didn't you want to use pointers? You're using C++, and
therefore pointers are to be used when it makes sense. And, it does
here. Trying to use references here means that you're creating lots of
*copies* of the units, so what you get back may not be what you
expect. Pointers won't do accidental copies. Your fear of pointers is
a pretty good possibility for why the effects of combat aren't
applied, as per your posting today.

For example:
struct hold{
vector<unit>at; //holds the attackers
vector<unit>dt; //holds the defenders
};
These should be vector<unit*>, to store pointers.
>void mapmgt::atIn(unit& u){
int x = u.getXloc();
int y = u.getYloc();
h[x][y].at.push_back(u);
Once again, use pointers in here. Otherwise, you'll copy the unit.

In C/C++, passing pointers is a good way to say "you can access
this, but you don't own it." Your map manager probably shouldn't own
all the units on the board, and it can't the way you wrote it above,
duplicating units. You have to either have the map manager own the
units, or use pointers. Pointers is the MUCH simpler solution. Don't
be afraid to use pointers. They're a skill you'll need to master for
C/C++.

Nathan Mates
--
<*Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Sep 19 '06 #52

Nathan Mates wrote:
In article <11**********************@h48g2000cwc.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
I took some of your advice and did my best to create a map manager
and so far it is working great. It is much easier and less buggy
than anything I could come up with. It was a challenge trying to
conceptualize the object. I didn't use pointers or anything and
creating the map was a challenge but so far the object does
everything I want it to do.

Why didn't you want to use pointers? You're using C++, and
therefore pointers are to be used when it makes sense. And, it does
here. Trying to use references here means that you're creating lots of
*copies* of the units, so what you get back may not be what you
expect. Pointers won't do accidental copies. Your fear of pointers is
a pretty good possibility for why the effects of combat aren't
applied, as per your posting today.

For example:
struct hold{
vector<unit>at; //holds the attackers
vector<unit>dt; //holds the defenders
};

These should be vector<unit*>, to store pointers.
void mapmgt::atIn(unit& u){
int x = u.getXloc();
int y = u.getYloc();
h[x][y].at.push_back(u);

Once again, use pointers in here. Otherwise, you'll copy the unit.

In C/C++, passing pointers is a good way to say "you can access
this, but you don't own it." Your map manager probably shouldn't own
all the units on the board, and it can't the way you wrote it above,
duplicating units. You have to either have the map manager own the
units, or use pointers. Pointers is the MUCH simpler solution. Don't
be afraid to use pointers. They're a skill you'll need to master for
C/C++.
I know that this is basic c++ stuff but if I do,

void mapmgt::atIn(unit& u){
int x = u.getXloc();
int y = u.getYloc();
h[y][x].at.push_back(u);
}

for(int lp = 0; lp < rteam.size(); lp++){
m.atIn(rteam[lp]);}
How do I read that as a pointer?
void mapmgt::atIn(unit * u)? Doent the Unit have to be apointer before
I can send it:
for(int lp = 0; lp < rteam.size(); lp++){
unit * prteam[lp];
m.atIn(prteam);}

I just don't work with pointers very much because when I do they tend
to lead to problems. I always thought the refrence thing was a good a
a pointer and much safer.

Sep 20 '06 #53
In article <12*************@corp.supernews.com>, na****@visi.com
says...
In article <11**********************@h48g2000cwc.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
I took some of your advice and did my best to create a map manager
and so far it is working great. It is much easier and less buggy
than anything I could come up with. It was a challenge trying to
conceptualize the object. I didn't use pointers or anything and
creating the map was a challenge but so far the object does
everything I want it to do.

Why didn't you want to use pointers? You're using C++, and
therefore pointers are to be used when it makes sense. And, it does
here. Trying to use references here means that you're creating lots of
*copies* of the units, so what you get back may not be what you
expect. Pointers won't do accidental copies. Your fear of pointers is
a pretty good possibility for why the effects of combat aren't
applied, as per your posting today.
His problem is not really to do with the use of pointers or references;
it is to do with making copies. He could make a copy in just the same
way if he used pointers where he currently used references. The
problem is that when given the reference, he is storing what is
referred to.

Now there is unfortunately a catch - you are basically stuck with
pointers in this case because you can't make a vector of references in
C++, so a vector of pointers is the correct solution. It is an
annoyance with C++ that references have certain limitations that mean
you sometimes have to revert to pointers.

All in all, though, it makes good sense to use reference syntax where
practical, and leave pointers for when they are needed (or, in rare
cases, where they make things clearer).

- Gerry Quinn

For example:
struct hold{
vector<unit>at; //holds the attackers
vector<unit>dt; //holds the defenders
};

These should be vector<unit*>, to store pointers.
void mapmgt::atIn(unit& u){
int x = u.getXloc();
int y = u.getYloc();
h[x][y].at.push_back(u);

Once again, use pointers in here. Otherwise, you'll copy the unit.

In C/C++, passing pointers is a good way to say "you can access
this, but you don't own it." Your map manager probably shouldn't own
all the units on the board, and it can't the way you wrote it above,
duplicating units. You have to either have the map manager own the
units, or use pointers. Pointers is the MUCH simpler solution. Don't
be afraid to use pointers. They're a skill you'll need to master for
C/C++.

Nathan Mates
--
<*Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Sep 21 '06 #54

Gerry Quinn wrote:
In article <12*************@corp.supernews.com>, na****@visi.com
says...
In article <11**********************@h48g2000cwc.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
>I took some of your advice and did my best to create a map manager
>and so far it is working great. It is much easier and less buggy
>than anything I could come up with. It was a challenge trying to
>conceptualize the object. I didn't use pointers or anything and
>creating the map was a challenge but so far the object does
>everything I want it to do.
Why didn't you want to use pointers? You're using C++, and
therefore pointers are to be used when it makes sense. And, it does
here. Trying to use references here means that you're creating lots of
*copies* of the units, so what you get back may not be what you
expect. Pointers won't do accidental copies. Your fear of pointers is
a pretty good possibility for why the effects of combat aren't
applied, as per your posting today.

His problem is not really to do with the use of pointers or references;
it is to do with making copies. He could make a copy in just the same
way if he used pointers where he currently used references. The
problem is that when given the reference, he is storing what is
referred to.

Now there is unfortunately a catch - you are basically stuck with
pointers in this case because you can't make a vector of references in
C++, so a vector of pointers is the correct solution. It is an
annoyance with C++ that references have certain limitations that mean
you sometimes have to revert to pointers.

All in all, though, it makes good sense to use reference syntax where
practical, and leave pointers for when they are needed (or, in rare
cases, where they make things clearer).

- Gerry Quinn
I went an used pointers. I thought refrences would work because I was
sending refrences to the function but that didn't work. Normally I
send refrences to objects to functions and the functions modify the
object but I have not stored those refrences in vectors or other
containers.

for(int lp = 0; lp < rteam.size(); lp++){
unit * pu = &rteam[lp];
m.atIn(pu);} //reads in the attracking units to map panager

Sep 21 '06 #55
In article <11**********************@k70g2000cwa.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
>I just don't work with pointers very much because when I do they
tend to lead to problems. I always thought the refrence thing was a
good a a pointer and much safer.
I'm going to put this bluntly: if you want to program C/C++
professionally, then you better be proficient in using pointers. Even
if you've botched things in the past or swallowed the line that
references are "as good," you're going to have to learn how to use
pointers. Memory management is a required skill for C/C++ programmers,
and the only way to effectively do that in the core language is with
pointers.

A reference is *not* equal to a pointer. There's a whole LOT of
ways they're different. The most obvious one is that references must
be initialized when defined, so that they point to valid data. A
pointer has no such restriction. As has already been pointed out, you
can't make a STL vector of references. Further, to allocate any
memory, you MUST account for the possibility that a memory allocation
failed. And that violates the #1 rule of references, that they point
to something valid.

Getting back to your code, the above raises a serious issue you're
going to need to sit down and think about for a while. Specifically,
memory management. Your map can have a fixed maximum size, that's not
serious and can be designed around. However, what goes *on* your map
isn't fixed. Assuming you have 'class Unit { ... };' for the things
placed on the map, the Units don't magically just appear in
memory. You *MUST* think through these questions:

1) When is a Unit created? By what function?
2) Who "owns" that memory?
3) When/how is that memory released?

So far, I guess you're doing something like this:

void DoSomething(void)
{
Unit unit1
DoSomethingElse(unit1);
}

In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
one good free reference, available for download at
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.

In order to properly create arbitrary numbers of units on your map,
you need to create them with the new operator. That doesn't allocate
on the stack, and instead gives you a pointer you can use. That
pointer should be passed to the MapManager instead, as I've
recommended from the beginning.
>I know that this is basic c++ stuff but if I do,
>void mapmgt::atIn(unit& u){
int x = u.getXloc();
int y = u.getYloc();
h[y][x].at.push_back(u);
}
Complete style nitpick: if you want anyone else to read your code,
then do NOT abbreviate this much. It makes your code a LOT less
readable. Write your header as follows:

void mapmgt::atIn(unit* u)

or, better yet

void MapManager::AddAttacker(Unit* u)
for(int lp = 0; lp < rteam.size(); lp++){
m.atIn(rteam[lp]);}
How do I read that as a pointer?
You've omitted all the definitions of these variables, and due to
overabbreviation, it's nearly impossible to figure out what these
variables are, and what you're trying to achieve here. Your map
manager should probably be a singleton, and a pointer retrieved. For
example

class MapManager
{
// ...
public:
static MapManager* Get(void);
//...
private:
static MapManager* s_Instance;
}

MapManager* MapManager::Get(void)
{
if(s_Instance = NULL)
s_Instance = new MapManager;

_ASSERTE(s_Instance); // Or some other form of error management
return s_Instance;
}

Then, in other code:

void SomeFunc(...)
{
MapManager* pMapManager = MapManager::Get();

Unit pAttacker1 = new Unit;
pAttacker1.SetPosition(5,5);
pMapManager->AddAttacker(pAttacker1);
}

Nathan Mates
--
<*Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Sep 21 '06 #56

Nathan Mates wrote:
In article <11**********************@k70g2000cwa.googlegroups .com>,
JoeC <en*****@yahoo.comwrote:
I just don't work with pointers very much because when I do they
tend to lead to problems. I always thought the refrence thing was a
good a a pointer and much safer.

I'm going to put this bluntly: if you want to program C/C++
professionally, then you better be proficient in using pointers. Even
if you've botched things in the past or swallowed the line that
references are "as good," you're going to have to learn how to use
pointers. Memory management is a required skill for C/C++ programmers,
and the only way to effectively do that in the core language is with
pointers.

A reference is *not* equal to a pointer. There's a whole LOT of
ways they're different. The most obvious one is that references must
be initialized when defined, so that they point to valid data. A
pointer has no such restriction. As has already been pointed out, you
can't make a STL vector of references. Further, to allocate any
memory, you MUST account for the possibility that a memory allocation
failed. And that violates the #1 rule of references, that they point
to something valid.

Getting back to your code, the above raises a serious issue you're
going to need to sit down and think about for a while. Specifically,
memory management. Your map can have a fixed maximum size, that's not
serious and can be designed around. However, what goes *on* your map
isn't fixed. Assuming you have 'class Unit { ... };' for the things
placed on the map, the Units don't magically just appear in
memory. You *MUST* think through these questions:

1) When is a Unit created? By what function?
2) Who "owns" that memory?
3) When/how is that memory released?

So far, I guess you're doing something like this:

void DoSomething(void)
{
Unit unit1
DoSomethingElse(unit1);
}

In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
one good free reference, available for download at
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.

In order to properly create arbitrary numbers of units on your map,
you need to create them with the new operator. That doesn't allocate
on the stack, and instead gives you a pointer you can use. That
pointer should be passed to the MapManager instead, as I've
recommended from the beginning.
I know that this is basic c++ stuff but if I do,
void mapmgt::atIn(unit& u){
int x = u.getXloc();
int y = u.getYloc();
h[y][x].at.push_back(u);
}

Complete style nitpick: if you want anyone else to read your code,
then do NOT abbreviate this much. It makes your code a LOT less
readable. Write your header as follows:

void mapmgt::atIn(unit* u)

or, better yet

void MapManager::AddAttacker(Unit* u)
for(int lp = 0; lp < rteam.size(); lp++){
m.atIn(rteam[lp]);}
How do I read that as a pointer?

You've omitted all the definitions of these variables, and due to
overabbreviation, it's nearly impossible to figure out what these
variables are, and what you're trying to achieve here. Your map
manager should probably be a singleton, and a pointer retrieved. For
example

class MapManager
{
// ...
public:
static MapManager* Get(void);
//...
private:
static MapManager* s_Instance;
}

MapManager* MapManager::Get(void)
{
if(s_Instance = NULL)
s_Instance = new MapManager;

_ASSERTE(s_Instance); // Or some other form of error management
return s_Instance;
}

Then, in other code:

void SomeFunc(...)
{
MapManager* pMapManager = MapManager::Get();

Unit pAttacker1 = new Unit;
pAttacker1.SetPosition(5,5);
pMapManager->AddAttacker(pAttacker1);
}

Nathan Mates

The criticizm is good. I know I have a great deal of work to do and I
often create smaller programs to learn how to do things. It is still
fun to create programs that do things and I am proud of the projects
that I complete. The purpose of these projects to have fun but also to
learn where I need to improve my skills. I am trying to do better in
my descriptions and commenting, I realize those are important.

I have made changes in my program based on the advice I have recieve
and it runs much better. I do read books on programming and some are
better than others and many times it seems that I get bad advice or
improperly implement the concepts. To learn I need to write programs
and make my mistakes. I got the program to run but there is much room
for improvment. The key to good programming is that it can be easily
expanded and this program is not designed that well as ti could be to
where it can easily be expanded. Often times, the advice I get and
ideas that come from writing I have to totally rewrite the program to
implement those changes or it is much easier. I have done that several
times as my knowlege has grown.

I have been on the lookout for good books that teach me these more
advanced methods of programming. I have only been doing this for a few
years and I am completly self taught. The best refrence I have is
Accelerated C++. I realize that book has limits and is very dificult
to fully grasp. I constantly re-read that book to keep getting the
knowlege out.

Sep 21 '06 #57
>
In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
one good free reference, available for download at
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.
This book has been recommended to me when I get the chance I am
planning to buy it. I need good resources to explain memory managment
and how best to use it. My skills are limited. I have the C++
programming language but often times I don't find the book useful and
often confusing. Mostly, I see the examples are too limited or I have
missed the parts that are useful.

Sep 21 '06 #58
In article <11**********************@m7g2000cwm.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
> In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
one good free reference, available for download at
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.
>This book has been recommended to me when I get the chance I am
planning to buy it.
As noted above, it's available for free (and legally, not pirated)
at the links above. Purchasing it is a great way to show support for
the author, but you can legally enjoy it now.

Nathan Mates
--
<*Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Sep 21 '06 #59

Nathan Mates wrote:
In article <11**********************@m7g2000cwm.googlegroups. com>,
JoeC <en*****@yahoo.comwrote:
In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
one good free reference, available for download at
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.
This book has been recommended to me when I get the chance I am
planning to buy it.

As noted above, it's available for free (and legally, not pirated)
at the links above. Purchasing it is a great way to show support for
the author, but you can legally enjoy it now.

Nathan Mates

I didn't see the links for the books. I will see if they are useful
for me. Still I realy can't stand reading off the screen. I will see
if there are sections that are worth printing out. Still I will look
over the book and probibly buy it. I just like the printed page
because reading off the screen is hard of the eyes. There are things I
need to learn and these book have been recommended to me at least two
times so I will buy it. AC++ was recommeneded to me several times and
I bought it and it is a great resuource.

Sep 22 '06 #60
"JoeC" <en*****@yahoo.comwrote in news:1158881588.228143.197380
@m7g2000cwm.googlegroups.com:
>
>>
In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
one good free reference, available for download at
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.

This book has been recommended to me when I get the chance I am
planning to buy it. I need good resources to explain memory managment
and how best to use it. My skills are limited. I have the C++
programming language but often times I don't find the book useful and
often confusing. Mostly, I see the examples are too limited or I have
missed the parts that are useful.
Yup. Thinking in C++ is a good book.

I'd actually suggest you start back at the beginnig - with the C
Programming Language. Doesn't cover C++ at all of course, but you should
be able to grok pointers a bit better after reading it.

You have a pile of memory in your computer. It can logically be viewed
as two things - the stack and the heap.

The stack keeps track of a bunch of things - two of which are of
importance to you. First is where to go when the particular function you
are in returns. The second is the locally created variables, which
include the parameters passed to the current function. When this
function returns, all of these local variables are destroyed.

The second is memory you've allocated on the heap. Any time you use
malloc, or the new operator, you allocate memory on the heap. These are
only going to go away if you use free or delete (which coorespond to
malloc and new). If you lose track of these, the memory has leaked.
Allocating memory returns a pointer to it.

When thinking about this, it doesn't hurt to actually draw pictures of
both your stack and heap, to see what gets put where, and when it goes
away.

A big problem that people seem to have is keeping track of when a pointer
is still valid, and when a piece of memory has been leaked. Deleting (or
freeing) a piece of memory marks that heap memory as fair game to be used
again by a subsequent new or malloc. It does not alter the value of any
pointers - which all still have the address of that piece of memory
stored away.

You need to make a serious effort to understand and control the lifespan
of memory allocated on your heap.

Good luck, keep reading, and keep asking questions.
Dan Lingman
nogotogames.com
Sep 22 '06 #61
In article <Xn*******************************@216.196.97.131> ,
Dan Lingman <dl******@rogers.com.nospampleasewrote:
A big problem that people seem to have is keeping track of when a pointer
is still valid, and when a piece of memory has been leaked. Deleting (or
freeing) a piece of memory marks that heap memory as fair game to be used
again by a subsequent new or malloc. It does not alter the value of any
pointers - which all still have the address of that piece of memory
stored away.
Two tricks that folks sometimes use to help debug problems in these
areas (and you ALWAYS have problems here, but especially if you're not
good with pointers) are...

* When you allocate a new object, leave some space in the debug-version
for a name, and fill it with the name of the function that allocated it.
Later, when you find this pointer leaked, you'll be able to see who
leaked it.

* Write a macro (#define) to free/destroy things, but ALSO null-out the
pointer. So, rather than

free (myPtr)
or
~MyObject()

do

#define DebugFree(ptr) free(ptr); ptr=null
or
#define DebugDestruct(obj) ~obj; obj=null

(leave off the trailing semi-colon, so you can logically write

DebugFree(myPtr);
or
DebugDestruct(obj);

Btw, if you want, you can make it so that, on non-debug-builds, you pull
the safeties off, although I think that's premature optimization.)

--
Please take off your pants or I won't read your e-mail.
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.
Sep 22 '06 #62
Miss Elaine Eos <Misc@*your-pants*PlayNaked.comwrote in
news:Mi************************@newsclstr02.news.p rodigy.com:

Two tricks that folks sometimes use to help debug problems in these
areas (and you ALWAYS have problems here, but especially if you're not
good with pointers) are...

* When you allocate a new object, leave some space in the
debug-version for a name, and fill it with the name of the function
that allocated it. Later, when you find this pointer leaked, you'll
be able to see who leaked it.
Nice idea - I'd not thought about plonking in a name for where my objects
came from - usually I've only got one factory per object type anyways, so
it's always the same function.
* Write a macro (#define) to free/destroy things, but ALSO null-out
the pointer. So, rather than

free (myPtr)
or
~MyObject()

do

#define DebugFree(ptr) free(ptr); ptr=null
or
#define DebugDestruct(obj) ~obj; obj=null

(leave off the trailing semi-colon, so you can logically write

DebugFree(myPtr);
or
DebugDestruct(obj);
Again, nice use on the macros. Just watch out for any other pointers to
the object - those will still be valid.

Cheers,
and thanks for the advice - I've been doing C/C++ for a while - always
nice to see a slightly different way of doing stuff.

Dan
Sep 22 '06 #63

Dan Lingman wrote:
"JoeC" <en*****@yahoo.comwrote in news:1158881588.228143.197380
@m7g2000cwm.googlegroups.com:
>
In this function, 'unit1' is created, for free, on the stack. [If
you don't know what that is, please sit down with C++ reference
manuals and
tutorials. http://www.mindview.net/Books/TICPP/...ngInCPP2e.html is
one good free reference, available for download at
http://www.planetpdf.com/developer/a...ContentID=6634 among
other places] However, at the end of DoSomething() [i.e., when it goes
out of scope], unit1 is gone. Destroyed.
This book has been recommended to me when I get the chance I am
planning to buy it. I need good resources to explain memory managment
and how best to use it. My skills are limited. I have the C++
programming language but often times I don't find the book useful and
often confusing. Mostly, I see the examples are too limited or I have
missed the parts that are useful.

Yup. Thinking in C++ is a good book.

I'd actually suggest you start back at the beginnig - with the C
Programming Language. Doesn't cover C++ at all of course, but you should
be able to grok pointers a bit better after reading it.

You have a pile of memory in your computer. It can logically be viewed
as two things - the stack and the heap.

The stack keeps track of a bunch of things - two of which are of
importance to you. First is where to go when the particular function you
are in returns. The second is the locally created variables, which
include the parameters passed to the current function. When this
function returns, all of these local variables are destroyed.

The second is memory you've allocated on the heap. Any time you use
malloc, or the new operator, you allocate memory on the heap. These are
only going to go away if you use free or delete (which coorespond to
malloc and new). If you lose track of these, the memory has leaked.
Allocating memory returns a pointer to it.

When thinking about this, it doesn't hurt to actually draw pictures of
both your stack and heap, to see what gets put where, and when it goes
away.

A big problem that people seem to have is keeping track of when a pointer
is still valid, and when a piece of memory has been leaked. Deleting (or
freeing) a piece of memory marks that heap memory as fair game to be used
again by a subsequent new or malloc. It does not alter the value of any
pointers - which all still have the address of that piece of memory
stored away.

You need to make a serious effort to understand and control the lifespan
of memory allocated on your heap.

Good luck, keep reading, and keep asking questions.
Dan Lingman
nogotogames.com
I know quite a bit about pointers refrences and regualr variables. I
just try to avoid using poitners because it can lead to problems if
they are misused. Mostly I try to use a reference when passing objects
to functions or vectors instead of arrays. A poitner is a good read
write iterator and is very useful with arrays. I have read that
dynamic memory is use for things like strings or arrays that you don't
know the size of unitl run time. Still those books are realy bad
because they don't teach the std::libs like string vectors and lists
which can relieve the novice use from haveing to use pointers.

I know that pointers are required for dynamic binding which I have
writrten a small program to learn. It is oten very useful to write a
handel to not have the user have to mess with poiters. The basic
problem I had in this questions was a misunderstanding on refrences and
pointers. Still know that pointers have to be cleaned up in c++ and is
is best to have objects take care of that for me.

Sep 22 '06 #64

Miss Elaine Eos wrote:
In article <Xn*******************************@216.196.97.131> ,
Dan Lingman <dl******@rogers.com.nospampleasewrote:
A big problem that people seem to have is keeping track of when a pointer
is still valid, and when a piece of memory has been leaked. Deleting (or
freeing) a piece of memory marks that heap memory as fair game to be used
again by a subsequent new or malloc. It does not alter the value of any
pointers - which all still have the address of that piece of memory
stored away.

Two tricks that folks sometimes use to help debug problems in these
areas (and you ALWAYS have problems here, but especially if you're not
good with pointers) are...

* When you allocate a new object, leave some space in the debug-version
for a name, and fill it with the name of the function that allocated it.
Later, when you find this pointer leaked, you'll be able to see who
leaked it.

* Write a macro (#define) to free/destroy things, but ALSO null-out the
pointer. So, rather than

free (myPtr)
or
~MyObject()

do

#define DebugFree(ptr) free(ptr); ptr=null
or
#define DebugDestruct(obj) ~obj; obj=null

(leave off the trailing semi-colon, so you can logically write

DebugFree(myPtr);
or
DebugDestruct(obj);

Btw, if you want, you can make it so that, on non-debug-builds, you pull
the safeties off, although I think that's premature optimization.)

--
Please take off your pants or I won't read your e-mail.
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.
My question is why do I want to mess with C? I went right into C++
because it is better. int * p = new p[x], is way better than
malloc(sizeof(int)) of how ever it is done correctly. Still I use the
std::libs for my every day arrays needs. Strings and vectors are much
better than passing a bunch of pointers around. There are refences
that are realy useful for modifying variables and objects inside of
functions, so I use them. I am reaching to do advanced things in my
programs. Things that may be byonde my ability as a programmer. It
can be like athletics or anything academic is you learn by pushing your
boundries. I don't do this for a living nor am I a student so my
mistases only result in a program falling or poor design. It takes a
great deal of work to get where I am and I intend to keep pushing my
boundries until I forced to write good code. That is my program will
not run. I am far from the point where performace of my code is vital
to my programs running. I probibly have to have some idea of inline
assembly fto get maximum performace of my programs.

I probibly need some classes or to take a course or two to be exposed
to some better programming techniques or to be forced to completly
understand and use some concepts that I ignore or overlook in my
programs. All I know I what I have read in books. If there is some
feature I don't think is useful, I generally skip over it or not fully
study it. I try to be fimilliar with the idea so I can go back and
learn it if it is somthing that I need to do to get a program running.
There are things that I know I don't understtand well like exception
handeling or unions or enum lists. I have read about them but haven't
found them useful. I recently got spun up on switch and case because
it was useful. I used for the winproc loop but never realy use it for
my own programs. It is somthing that now because it is better for what
I was doing, I learned it.

I just pretty much finished my map game. It runs pretty well. It is a
fairly complex program expically that I as a complete amature with no
formal education cranked out. Yes, there is massive room for
improvment. Some improvments can be made in the exiesting code but as
I look at what I have done it would be better to start from scratch to
realy make the program better. May be in the future, I will add more
unit types and have them be loaded in from files. I might have some
way to control cities and have output. I might add some things that
allow the players to see unit stats. I am not sure. There are
internal things I could do to make the program better but most of those
require that I re-write the program. I might do that at some future
time. Ar least for now, I am going to stop for a while and do some
studying try to learn new things and see what I feel like doing for my
next project.

Sep 22 '06 #65

Dan Lingman wrote:
Miss Elaine Eos <Misc@*your-pants*PlayNaked.comwrote in
news:Mi************************@newsclstr02.news.p rodigy.com:

Two tricks that folks sometimes use to help debug problems in these
areas (and you ALWAYS have problems here, but especially if you're not
good with pointers) are...

* When you allocate a new object, leave some space in the
debug-version for a name, and fill it with the name of the function
that allocated it. Later, when you find this pointer leaked, you'll
be able to see who leaked it.

Nice idea - I'd not thought about plonking in a name for where my objects
came from - usually I've only got one factory per object type anyways, so
it's always the same function.
* Write a macro (#define) to free/destroy things, but ALSO null-out
the pointer. So, rather than

free (myPtr)
or
~MyObject()

do

#define DebugFree(ptr) free(ptr); ptr=null
or
#define DebugDestruct(obj) ~obj; obj=null

(leave off the trailing semi-colon, so you can logically write

DebugFree(myPtr);
or
DebugDestruct(obj);

Again, nice use on the macros. Just watch out for any other pointers to
the object - those will still be valid.

Cheers,
and thanks for the advice - I've been doing C/C++ for a while - always
nice to see a slightly different way of doing stuff.

Dan
This is a fustration for many of us non-educated programmers. We often
are not exposed to many things. It may be that books overlook them or
that I don't grasp the importance of some topiocs.

Sep 22 '06 #66
In article <11*********************@i42g2000cwa.googlegroups. com>,
"JoeC" <en*****@yahoo.comwrote:
My question is why do I want to mess with C? I went right into C++
because it is better.
If I read the previous poster correctly (and I concur with this
sentiment), it appears from your questions that you are missing some
training in fundamental concepts that are difficult to learn in C++
without a strong C background.

It's a little as if you'd jumped into advanced triganomatry problems
without a strong understanding of either geometry or algebra. Sure, you
could back-learn, but you really need a better handle on the prereqs
before you go too far in the advanced topics.

For one thing, the explanation for many C++ things is "it's like foo in
C, except you do bar instead of sna, and it gives you better control
over your afus."

--
Please take off your pants or I won't read your e-mail.
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.
Sep 22 '06 #67

Miss Elaine Eos wrote:
In article <11*********************@i42g2000cwa.googlegroups. com>,
"JoeC" <en*****@yahoo.comwrote:
My question is why do I want to mess with C? I went right into C++
because it is better.

If I read the previous poster correctly (and I concur with this
sentiment), it appears from your questions that you are missing some
training in fundamental concepts that are difficult to learn in C++
without a strong C background.

It's a little as if you'd jumped into advanced triganomatry problems
without a strong understanding of either geometry or algebra. Sure, you
could back-learn, but you really need a better handle on the prereqs
before you go too far in the advanced topics.

For one thing, the explanation for many C++ things is "it's like foo in
C, except you do bar instead of sna, and it gives you better control
over your afus."

My history of learning computers consited in a few highshool basic and
pascal cources. then I did some basic progtamming on a ti-99 and
Apples. It wasn't until about 15 years later that I picked up html
then perl and finally C++. When it comes to learning C first why not
first understand assembly before C to better understand it. C is
better than assembly and so is C++. My two first books with C++ were
C++ in 24 hours. That was a good overview of the basics then I went
into AC++. That book showed me how to get things done and treat the
std::libs as part of the language. Why should I have to do char *
name[] = "name" then deal with all the strlens and pointers when I can
just get somthing done with std::sting name = ....;

I do write fairly complex programs with my knowlege base. And those
projects teach me a great deal about how to do my next project. I do
read computer books and often I come accross parts that I don't reate
to or have an idea how to use. I try to read as much as I can and try
to file it away in case I come accross a situation where it might be
useful.

I am can do quite a bit. I know there is a vast body of knowlege I yet
to learn. So much I don't know. I find the interaction with more
experienced programmers here extremely useful. I realy get so much out
of the openenended questions than just some question over syntax. I
have the disability of not being around programmers so I miss out on
the attitude of how to think or the approach to problem solving. I
marvel at those who have higher skill than I do. I always look to ways
I can improve my programs. Uusally I take simple problems and work on
them. It can be a way to look at objects or some way to condence code.
When I do my projects I write them the best I can. In the end my first
goal is to get it to work with the skills I have. There are times when
I write poor code to get somthing to work and by the time I get back to
that code it causes too many problems to fix. What I then do is my
next project I try to solve a simmiliar problem better and I better
understand why I should write code in a different way.

Sep 23 '06 #68
In article <11*********************@d34g2000cwd.googlegroups. com>,
"JoeC" <en*****@yahoo.comwrote:
If I read the previous poster correctly (and I concur with this
sentiment), it appears from your questions that you are missing some
training in fundamental concepts that are difficult to learn in C++
without a strong C background.
[...]
My history of learning computers consited [...]
Btw, I didn't mean my previous to be in the slightest bit insulting.
I'm sure you're a fine programmer and a very smart person. All I was
trying to say is that your questions seem to indicate that you're
missing some fundamentals that are easier to grasp in C, which may be
why folks suggested you back up & try going fwd from there.

It's a little like if I started asking all sorts of compiler questions,
pretty soon it'd be obvious that I'd never learned whatever it is they
teach folks in compiler courses. Hence, my "I'm 2/3 of the way through
writing my compiler, but running into foo-related problems" might be met
with "you need to back up and start way back near the beginning with
your (oh, I don't know...) tokenizer (let's say.)

This doesn't mean that I'm stupid or a bad programmer, only that my
questions would indicate to the experts that I was a bit lost in
compiler-land.

See what I mean?

Now, maybe we've read you correctly, maybe not -- but that's what it
looks like, from the kinds of things you're asking, and that's why we're
recommending the things we do.

"No offense", and all that :)

--
Please take off your pants or I won't read your e-mail.
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.
Sep 23 '06 #69
JoeC wrote:
My main point for this whole post is to get an opinion on what I wrote.
Yes it is not very good. But I am looking for a concept on how go
about making it better.
I haven't looked at your code, but I do have some advice that I think
might be useful.

A function, class, method, whatever, should do one thing. It should do
that one thing well and it should do that one thing exclusively.

If you have a function or a class or anything that "figures out what
units occupy the same space and then does combat and then figures out
what to do with the results," then that one thing is doing too many
things.

I'd personally steer away from anything like a "map manager," but that's
just because I think that managers in general serve only to obfuscate
the code overall. See Ward's Wiki's thoughts on the matter here:
http://c2.com/cgi/like?DontNameClass...rHandlerOrData
Great seperate the sorting and combat into two functions.
Yep. ;)

You could have a function that takes the list of entities and returns a
list of lists of entities that share the same space on the map. That'd
be pretty easy to do in linear time on the number of units in the map.
(Create a list of entities for each square, then run through the entity
list adding each entity to the right list.) Then, you have a function
that takes a list of units and resolves combat between them. That
function doesn't need to consider that the units may or may not be in
the same space; indeed it's probably better if it doesn't because then
it allows you to add ranged attacks later and the fact that the units
are or are not in the same space is only relevant to determining the
lists that you send to the combat function in the first place.
That would be good but they have to be sorted before combat can take
place.
Surely whether or not the units are sorted isn't relevant to the actual
combat algorithm though, right? The sorted-or-not question is only
relevant from a higher-level gameplay perspective.
Should I have a combat object that sorts and then does the combat.
Nope, and I say that because of the fact that you used the words "and
then" in there.
Should I create a sort object then have that object loaded by the
combat routine.
How about get the results from the sort object (although I'm not sure
what purpose a "sort object" would have that couldn't exist solely in a
sort function) and feed that to the combat routine?
I know it is best to break it all down to the simplest steps but I have
a proscess here. Sort, combat, results.
Exactly. ...although I'm also not sure that "sort" is the right term
for what you're trying to accomplish...

In Python, you might say:

def OneGameTick():
sortedEntities = Sort(entities)
combatResults = ExecuteCombat(sortedEntities)
Render(combatResults)
My problem is that I ham having trouble seperating out the steps.
You've already come part way. Just work from there.
It it not simple.
It is, actually. It just takes some time to start recognizing the
patterns. ;) Write the whole sequence out in plain English (or Latin
or French or whatever), and there you go. You've got your steps.
1. find units in the same space,
2. get the combat factors,
3, resolve combat,
4. apply results to affected units.
Ok this is different from above but the process is similar. If you want
to get the combat factors every game tick, then do that too!

def OneGameTick():
sortedEntities = Sort(entities)
combatFactors = GetCombatFactors()
combatResults = ExecuteCombat(combatFactors, sortedEntities)
Apply(combatResults)
Some of these problems are harder than others.
Certainly. However, breaking them down sufficiently makes every problem
appear trivial.

Good luck!

-tom!

--
Sep 26 '06 #70

Miss Elaine Eos wrote:
In article <11*********************@d34g2000cwd.googlegroups. com>,
"JoeC" <en*****@yahoo.comwrote:
If I read the previous poster correctly (and I concur with this
sentiment), it appears from your questions that you are missing some
training in fundamental concepts that are difficult to learn in C++
without a strong C background.
[...]
My history of learning computers consited [...]

Btw, I didn't mean my previous to be in the slightest bit insulting.
I'm sure you're a fine programmer and a very smart person. All I was
trying to say is that your questions seem to indicate that you're
missing some fundamentals that are easier to grasp in C, which may be
why folks suggested you back up & try going fwd from there.
I do read the basics of programming and I have devloped my techiques.
I am always trying to improve those techniques. I am self taught and
have little contact with other programmers. I ask what ever question
is on my mine and I can't get a good answer in a book.
>
It's a little like if I started asking all sorts of compiler questions,
pretty soon it'd be obvious that I'd never learned whatever it is they
teach folks in compiler courses. Hence, my "I'm 2/3 of the way through
writing my compiler, but running into foo-related problems" might be met
with "you need to back up and start way back near the beginning with
your (oh, I don't know...) tokenizer (let's say.)
I couldn't immagine wiriting a compiler although I would like to do
some basic assembly programming some day just as I have done some
research into Latin. I am starting to write larger programs and I have
choices on how I can design the parts of that program and often wonder
which ways are the best. I just got my map game to run correctly. In
the proscess of writing that game as I go back there are better ways I
could have written some parts of that program. Going back to make
changes would result in far more effort trying to make the rest of the
program accept those changes.
>
This doesn't mean that I'm stupid or a bad programmer, only that my
questions would indicate to the experts that I was a bit lost in
compiler-land.
I have doubts about my abilities despite what I create. I know I have
it in my to do better and write even better programs even at my current
skill. I also look for ways to write small programs to learn new ways
of doing things and new skills. I often avoid some directions because
of some lack of knowlege. I always try to know what I want to do then
how to do it.

I am planning a complete re-write of my game I just don't think I have
learned enough lessons to make it worh wile. Some of the ideas I have
is to have units dynamic and have several kinds. Load the unit data
from a file, conquer cities and have a production value and create new
units in play. A better combat system and have ranged attacks. Still
my thoughts are too disorginized to continue. I am taking a break and
re-writing some of the libraries with the ideas and knolwege I have. I
so far have created a coor struct and a new color object. Still Many
of the questions I have are should a unit be a graphic or have a
graphic should the color be part of the unit or the graphic. What if I
want to create one unit or army from several units. Kind of a tree.

Yes, I am dangerous and I am facinated by programming especially by
C++.
>
See what I mean?

Now, maybe we've read you correctly, maybe not -- but that's what it
looks like, from the kinds of things you're asking, and that's why we're
recommending the things we do.

"No offense", and all that :)
Don't worry. I am currenly at a loss for direction. I can study but I
am not sure what to study next. What topic or better knowege is the
best use of my time. Of course you don't know that, it is up to me. I
gain so much from open ended discussions. A question I often ask
myself is not what to think but how to think as a programmer.

A big fustration is that I have the C++ programming language. I often
study AC++ a priceless resource. Still there is only so much
informations there. C++ PL is often dificult to learn anything from.
I often get confuced because there is just as much what not to do as
what is correct.

Right now I am writing little pointer programs. When I get lost in the
big things, I go to small programs and focus on improving my skills
with specific syntax.

Sep 26 '06 #71
LR wrote:
Perhaps you should look into std::map, or maybe std::multimap.

Just as a thought experiment, not the way to write your code, think
about something like std::map<Location, std::set<UnitIndicies.
Let's consider that simple things are more expressive and easier to
understand than complex things.

struct Entity
{
int x, y;
};
typedef std::list<Entity*EntityList;

EntityList g_theEntities;

EntityList GetObjectsAt(int x, int y)
{
EntityList list;
for (EntityList::const_iterator it = g_theEntities.begin();
it != g_theEntities.end(); ++it)
{
Entity* e = *it;
if ((e->x == x) && (e->y == y))
{
list.append(e);
}
}

return list;
}

Then no 'manager' or other "god object" needs to maintain any info; the
entities can take care of knowing where they are themselves.

-tom!

--
Sep 26 '06 #72
LR
Tom Plunket wrote:
LR wrote:

>>Perhaps you should look into std::map, or maybe std::multimap.

Just as a thought experiment, not the way to write your code, think
about something like std::map<Location, std::set<UnitIndicies.


Let's consider that simple things are more expressive and easier to
understand than complex things.
I'm not entirely sure that I agree with that. For example, "expressive"
is a fairly complex word. What would it take to express your thought if
you didn't have that word available.

By the same token, we might be better served by adding some operations
that work on an Entity. Or maybe, if an Entity has a Location, then we
might be better off with something like this.

(None of this code was compiled or tested, so caveats apply.)

class Location {
int x_, y_;
public:
Location(const int x, const int y) : x_(x), y_(y) {}
// and other members as appropriate
};

and I'm not showing the implementation of these, pretty obvious.

bool operator<(const Location &l1, const Location &l2) { ... }
bool operator==(const Location &l1, const Location &l2) { ... }
So, if I understand your intent correctly, then
struct Entity
{
Location location_;
SomeOtherDataThatAnEntityHas d_;
};


I do worry about making containers of pointers. Who owns the pointer?
typedef std::list<Entity*EntityList;
EntityList g_theEntities;

If we make the argument a Location then we're not in any doubt about
what x and y are for, and since we'll probably be using a Location from
another object anyway, it might be easier to call
EntityList x = GetObjectsAt(enitity.location_);
than
EntityList x = GetObjectsAt(entity.x,enitity.y);
just my opinion,
EntityList GetObjectsAt(const Location &loc)
{
EntityList list;
for (EntityList::const_iterator it = g_theEntities.begin();
it != g_theEntities.end(); ++it)
{
Entity *e = *it;
// this seems better to me than comparing the
// x and y things explicitly, because we might
// want to change what a location is and this
// will be a little easier.
// I think that it has the advantages of being
// more _expressive_ and tucking the complexity
// of the code away somewhere else. Plus, we'll
// probably find that we can use it elsewhere.
if(loc == e->location_)
{
list.append(e);
}
}

return list;
}

Then no 'manager' or other "god object" needs to maintain any info; the
entities can take care of knowing where they are themselves.
I guess it depends on how you want to manage the entities and where
they're going to exist during the lifetime of the program.

BTW, one of my concerns about the list of pointers to Entities involves
making a copy of the entire game. Who knows why we'd want to do that.
Maybe to allow the code to try some strategy to beat its opponent. With
something like:
(In this example, an Entity has no Location.)
typedef std::map<Location, std::vector<Entity Board;
Board a;
doSomething(a);
Board b(a);
if(somethingDestructiveWorksOut(b)) {
// we still have our old a.
// although this might be expensive.
}

LR
Sep 26 '06 #73
LR wrote:
By the same token, we might be better served by adding some operations
that work on an Entity. Or maybe, if an Entity has a Location, then we
might be better off with something like this.
Sure, simple doesn't mean operation-free. Indeed, adding to an object's
API may indeed simplify the use of that object.
class Location {
int x_, y_;
public:
Location(const int x, const int y) : x_(x), y_(y) {}
// and other members as appropriate
};

and I'm not showing the implementation of these, pretty obvious.

bool operator<(const Location &l1, const Location &l2) { ... }
bool operator==(const Location &l1, const Location &l2) { ... }
So, if I understand your intent correctly, then

struct Entity
{
Location location_;
SomeOtherDataThatAnEntityHas d_;

};
Yep.
I do worry about making containers of pointers. Who owns the pointer?
typedef std::list<Entity*EntityList;
It was easy for me to type it in. ;)

I'd say the thing that creates the pointers owns them, which is to say
that the thing that initially populates the "g_theEntities" list (which
is the likely place the objects would be created in the first place)
would be responsible for depopulating it.
If we make the argument a Location then we're not in any doubt about
what x and y are for, and since we'll probably be using a Location from
another object anyway, it might be easier to call
EntityList x = GetObjectsAt(enitity.location_);
than
EntityList x = GetObjectsAt(entity.x,enitity.y);
just my opinion,
I agree 100%, and would suggest that while this adds lines-of-code, this
makes the code more expressive and easier to understand. "What is this
argument here for? Oh, it's a Location. Done."
// this seems better to me than comparing the
// x and y things explicitly, because we might
// want to change what a location is and this
// will be a little easier.
// I think that it has the advantages of being
// more _expressive_ and tucking the complexity
// of the code away somewhere else. Plus, we'll
// probably find that we can use it elsewhere.
if(loc == e->location_)
I agree.
Then no 'manager' or other "god object" needs to maintain any info; the
entities can take care of knowing where they are themselves.

I guess it depends on how you want to manage the entities and where
they're going to exist during the lifetime of the program.
Either objects can manage themselves (often the simplest solution IMO),
the thing that naturally contains them can manage them, or some third
party (aka "the manager") can manage them.
BTW, one of my concerns about the list of pointers to Entities involves
making a copy of the entire game. Who knows why we'd want to do that.
Maybe to allow the code to try some strategy to beat its opponent. With
something like:
Sure. When you find yourself trying or needing to do that, make the
code do it. Engineering a solution to that before you have a need is
quite possibly a waste of time, and if you keep all of your parts simple
it won't be hard to make the code do different things under the hood to
facilitate such work.

-tom!

--
Sep 27 '06 #74

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

60 posts views Thread by Fotios | last post: by
reply views Thread by Tony Johansson | last post: by
2 posts views Thread by Simon Harvey | last post: by
24 posts views Thread by cassetti | last post: by
14 posts views Thread by rabbitrun | last post: by
15 posts views Thread by bruno.desthuilliers | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by kmladenovski | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.