Standard containers, polymorphic objects, and memory management.

[Daniel Pitts]

I'm trying decide on the best way to structure the memory management in
my program.

I have a class (lets call it World), which contains a collection of
Entity objects.

Entity in turn, contains a pointer a Shape object. Shape is a pure
virtual class.

Now, I'm not sure who should "own" the allocation and deallocation of
the Shapes. It makes sense that World should own the Entity objects
directly, but it seems to complicate matters if I want the Entity
objects to delete (through auto_ptr, or on there own destructor) the
Shape *.

Also, I'd prefer (although its not a requirement) to avoid the "new"
operator for a lot of this. eg, I'd like to do something like this:

World world;
world.addEntity (Entity(new Sphere(spherePa rams)));

where you have:
void World::addEntit y(Entity &entity) {
entities.push_b ack(entity);
}

Now, if Entity deletes its shape on destruction, I need to make sure
that the Entity copy constructor uses move semantics, but I'm not sure
that's compatible with std::vector<Ent ity>. Or I need to make World
accept (and manage) Entity pointers.

I suppose I could also make it so that World manages the Shape object
life-cycle, eg "Shape &shape World::addShape (Shape *shape);".

So, any suggestions on which route I should take?

Thanks,
Daniel.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity .net/wordpress/>

[Amal Pillai]

I have a class (lets call it World), which contains a collection of

Entity objects. Entity in turn, contains a pointer a Shape
object. Shape is a pure virtual class.

Your description looks like this:

class Shape
{
// one or more pure virtual functions

};

class Entity
{
std::auto_ptr<S hapes_; // or shared_ptr<Shap e>
// ...

// has copy ctor & assignment op
// by either cloning or sharing the pointee.

};
class World
{
std::vector<Ent ityentities_;
// ...
};

So assuming you have a single World instance, memory management seems
to be taken care of.

Now, if Entity deletes its shape on destruction, I need to make sure
that the Entity copy constructor uses move semantics, but I'm not
sure that's compatible with std::vector<Ent ity>. Or I need to make
World accept (and manage) Entity pointers.

You can ensure that Shape has clear clone semantics or use shared_ptr
idiom to make it compatible to vector<Entity>. I would advise against
use of raw pointers.

-Amal

[James Kanze]

On Jun 3, 4:36 am, Daniel Pitts
<newsgroup.spam fil...@virtuali nfinity.netwrot e:

I'm trying decide on the best way to structure the memory
management in my program.

I have a class (lets call it World), which contains a
collection of Entity objects.

Entity in turn, contains a pointer a Shape object. Shape is a
pure virtual class.

Now, I'm not sure who should "own" the allocation and
deallocation of the Shapes. It makes sense that World should
own the Entity objects directly, but it seems to complicate
matters if I want the Entity objects to delete (through
auto_ptr, or on there own destructor) the Shape *.

Be careful with the concept of ownership. In most applications,
it doesn't really make sense to have a "world" object which owns
the entity objects, but rather the let the entity objects "own"
themselves. And do Shape objects really require destruction; do
they have a deterministic lifetime. If not, then the simplest
solution is to use a garbage collector, and not worry about it.

Otherwise, I don't think that there's any real problem in having
Entity be responsible for the lifetime of its Shape. But of
course, this will really depend on the actual semantics of the
objects in question. There is no one rule which fits all cases.

Also, I'd prefer (although its not a requirement) to avoid the
"new" operator for a lot of this.

If you're objects are polymorphic, you don't have much choice.

eg, I'd like to do something like this:

World world;
world.addEntity (Entity(new Sphere(spherePa rams)));

where you have:
void World::addEntit y(Entity &entity) {
entities.push_b ack(entity);
}

Why? Entity objects typically have identity, which means that
they don't support copy or assignment; they usually also have an
arbitrary lifetime. Both of which mean that they should
probably never be allocated other than dynamically.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]