Re: Is there a design pattern for holding the same pointers in many arrays?
On Nov 7, 9:46 am, Juan Pedro Bolivar Puente <raskolni...@es.gnu.org>
wrote:
Back to your original question, I propose the following approach, though
not perfect:
a) Separate interface from implementation. Interfaces have an empty
implementation until the lowest classes in the hierarchy -- concrete
entities. They can be easily combined via virtual inheritance, etc..
For example, you could have a SpatialEntity (that adds set_position,
get_position), a DynamicEntity : SpatialEntity that adds (set_speed,
get_speed), a GraphicalEntity : SpatialEntity that adds (draw) and so
on. Then you have the implementation in different objects that you
integrate in the interface manually. For example:
[code]
This is only a proposal. As you can see, this works well when part of
the implementation of your entity compononents is defined by third party
libraries. In other cases you can add more behaviour to the interfaces,
etc...
To make sure i understand, is your suggestion that if i want an object
to be square, have it derive from a Shape decendent that adds square
data, or hold a Shape pointer to a decendent of Shape holding square
data?
PS: I would be interested in reading your source code :D
I suppose the problem is complex enough to deserve a case study
anyway.
There are actually two projects that demonstrate two parts of the
problem. The first uses only circular collision, so there is no shape
data, but multiple lists are used for things that can collide and
things that can't (named cActors and particles, respectively). This
can all be found in main.cpp.
https://github.com/splinterofchaos/Gravity-Battle
The second includes two types of shape, points and loops. Collision.h
is relevant. Playfield.h and Gunman.h inherit from classes defined in
Collision.h. They're used in main.cpp.
https://github.com/splinterofchaos/Shoot-the-Floor
On Nov 8, 7:23 am, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
Hak...@gmail.com wrote:
I'm making a real-time graphical application (video game) and i want a
list of every graphical object, a list of every circular object,
square object, every physical object, etc. Many applications even have
so-called buckets, which ensure that certain objects are updated
before others.
I guess the answer is performance, but still I'll ask the question: Why do
you need these lists? You could store the objects in a single list and when
you want to access all circular objects, you visit every object with an
according visitor (look up "visitor pattern" aka "double dispatch") that
does nothing for non-circular objects.
Perhaps i didn't explain it well. Having everything in one list means
that every feature that some set of objects have and another lack has
to be determined dynamically. Whether an objects collides or not can
be determined by a virtual function like B::can_collide, we've covered
shape detection, buckets can be avoided by sorting the entity list...
the point is there's a way to get around anything, but if everything
was in separate lists, features would be known statically. It's not
just about performance (which is the least of my worries), rather
removing the need to have such complicated work-a-rounds.
Every time a new list is added, code complexity grows. If i want to
create an object of type X, i currently have a function similar to:
template< typename T >
T* spawn() {
T* x = new T;
graphicalObjects.push_back( std::shared_ptr<T>(t) );
return x;
}
and it works fine, assuming there is only one list.
This is one of the worst mixtures of smart and raw pointers I have ever
seen. You should definitely return the smart pointer instead:
template<typename T>
shared_ptr<T> spawn()
{
shared_ptr<T> res(new T);
graphicalObjects.push_back(res);
return res;
}
If i have many lists, how can this spawn function figure out what lists
to put it in?
I suppose many would answer that it depends on how class X is defined,
but that is liable to change based on the solution to this problem.
The only restraint is that i have a base class, B, and everything
inherits from that.
I'd suggest the visitor pattern again. Another option is that you pass a
reference to the "environment" to the objects' ctor (or a separate init
function), and they add themselves to the according lists there.
I don't understand what you mean pass a reference to the envrionment
to the objects' ctr. Do you mean pass a reference to the lists it has
to add itself to, or a container holding each list? I am hopping to
make my objects agnostic of what lists exist so that i can have
extremely loose coupling. Then again, maybe that's not possible.
The other question is how to handle removing an object from each list
it's in.
I'd do it similarly to how you added it, either using a visitor or a virtual
function that knows what lists to delete the object from. Of course, you
can't use the destructor, because the object won't be destroyed until
before it was deleted from those lists. A way around this would be the use
of weak_ptr, which is a shared_ptr without the ownership, i.e. it
automagically goes zero when the last shared_ptr is destroyed.
That sounds like it will solve many of my problems, the weak_ptr. :) I
think the spawn function would be better if it returned a weak_ptr.
What are you doing with those lists? The answer to your question probably
depends on that. If all you do is e.g. first draw all circular objects,
then draw all rectangular objects etc, you could as well implement a
visitor that draws the object according to its type.
In either of the links posted above, main.cpp contains everything.
Mostly everything is just in one list and most functions only require
a for_each. First move is called for each object, collision is
checked, then draw is called. The first link is the only of the two
with two lists because some objects do not collide, so move is called
for for all in one list, then collide, and then move is called for the
other list. Ideally, there could be one list that holds every object
that can be drawn and two more lists: one that calls move and checks
collision, the other that just moves.
In the second link, there is one list, but there could be three as
well. Everything is moved and drawn the same way, but two lists could
help statically know whether something is a point, physically, or a
circle.
This problem is not particular to any specific project. I don't even
know if it's right for either project i'm working on. However, adding
more lists seems far easier, mor general, and more scalable than
implimenting double dispatches and other such work-a-rounds for every
such problem.
Maybe i wouldn't even have this problem if i hadn't been ignorant of
the weak_ptr. If i can make my spawn function specialized for each
type, it could know what lists to add weak_ptrs to and removing it
from those lists would be a sinch since they'll becom null when the
shared_ptr is deleted.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]