Re: Logic question...

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!

--

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

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!

--