Instancing memory management

If it's loaded from disk (an asset) it should always be const
If it changes at runtime, it must belong to the instance class.
In addition, the instance requires a single pointer to the asset it is using....

That is about as simple as you can get. (and most game developers will use something very similar)

[color=#1C2837][size=2]Is there a good way to not have to make the programmer pay attention to every single piece of memory, not use all kinds of managers in between objects, and not let the memory dangle until the application shuts down.[/quote]
[color="#1C2837"]

[color="#1C2837"]In a word no. There may be things you can do to make it easier, but in general most game developers care a great deal about the memory usage (and fragmentation). This is especially true on consoles due to the severe restrictions placed upon you with the amount of memory you have etc.

Have you considered using smart pointers?

Have you considered using smart pointers?

What do smart pointers have to do with instancing?
From what know smart pointers are simple classes with a pointer as a member variable which has been put on the stack, and that way it gets deleted automatically when going out of scope, and when being deleted the class also deletes the pointer.
First of all, this has nothing to do with my problem.
Secondly, when you would use this on instancing, for example, 2 entities with the same mesh, and both entities get deleted, which entity will delete the mesh?
It's not very hard to manage with just meshes and entities as these are big objects and there probably isn't a lot of them.
But when you get a bigger tree, like entity -> mesh -> material -> texture, things get messy.
Also, when I for example load a material file, it automatically loads a texture, because the texture file path is stored in the material file.
Same goes for a mesh, it stores the material that has to be attached to it.
The programmer would then have to delete something that he has never told the program to create.

First of all, this has nothing to do with my problem.
Secondly, when you would use this on instancing, for example, 2 entities with the same mesh, and both entities get deleted, which entity will delete the mesh?

Um... This is what smart pointers solve.

You don't delete anything. Instance is deleted as soon as it's no longer used. As long as at least one reference is held, smart pointer does nothing. When nobody else is holding the reference, smart pointer deletes the instance.

No entity explicitly deletes the mesh. Smart pointers keep reference count, when it drops to zero, it's automatically deleted.

But when you get a bigger tree, like entity -> mesh -> material -> texture, things get messy.[/quote]Yes and smart pointers (reference counted/mark-and-sweep) keep track of which objects are still being referenced and which aren't. When there are no more references, smart pointer releases the resources.

From what know smart pointers are simple classes with a pointer as a member variable which has been put on the stack, and that way it gets deleted automatically when going out of scope, and when being deleted the class also deletes the pointer.[/quote]
Yes. Which is precisely what you are looking for. When something goes out of scope (scope extends beyond just function), application can no longer reference them. So it is automatically deleted. This principle recursively applies to reference chains, so objects referencing other objects go out of scope, are deleted, etc.


A better example is shared_ptr, which is also part of standard library these days. auto_ptr linked in above example is obsolete and superseded by unique_ptr.

But when you get a bigger tree, like entity -> mesh -> material -> texture, things get messy.

Entity is the user of the resource, it doesn't own the resource, so it should not free the resource.
The resource itself is just a piece resource (the real data) used by others, so it can't manage its life time.
A resource manager should response to free the resource.
When any entity doesn't need a resource, it just tells the resource manager and the resource manager decides if to free the resource (no one use it) or not.
This scheme can also help to optimize memory usage. For example, even nobody uses the resource, if the free memory is enough, the manager can delay the free of the resource to avoid unnecessary disk IO when resource is used again.

Personally I prefer to clear memory ownership to shared pointer (which cause the ownership unclear).

I guess my understanding of smart pointers was wrong.
A shared pointer indeed seems to be a good solution.