Logic question...

[JoeC]

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/ThinkingInCPP2e.html is
one good free reference, available for download at
http://www.planetpdf.com/developer/article.asp?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.

 

[Dan Lingman]

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/ThinkingInCPP2e.html is
one good free reference, available for download at
http://www.planetpdf.com/developer/article.asp?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

 

[Miss Elaine Eos]

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.)

 

[Dan Lingman]

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

 

[JoeC]

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/ThinkingInCPP2e.html is
one good free reference, available for download at
http://www.planetpdf.com/developer/article.asp?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.

 

[JoeC]

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.)

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.

 

[JoeC]

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.


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.

 

[Miss Elaine Eos]

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."

 

[JoeC]

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.

 

[Miss Elaine Eos]

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.

[/QUOTE]
[...]

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

 

[Tom Plunket]

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?DontNameClassesObjectManagerHandlerOrData

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!

--

 

[JoeC]

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.[/QUOTE]

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.

 

[Tom Plunket]

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!

--

 

[LR]

LR wrote:




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

 

[Tom Plunket]

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?

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.

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!

--