Memory Handling and Containers

[bana]

Thanks for the wonderful answers everyone.

On the memory topic: What are the most common constructions for memory handling used in Ogre, Ode etc.. ie: is there a more often than not used technique (linked lists, octrees, hash tables, etc..), or is it just scattered in an organized, yet non-connected way?

[epopov]

I'm not sure you need to code some special structures to handle memory these days (except if you build a memory manager !).
When you need to create something, you just do 'new Something'. Then, if you need to retain the pointer, you either put it in one of your own class or in a STL container (and then it's up to the container to handle memory usage for the object list).
In some very particular instances you may need to overload the new operator on a class, if you perform lots of 'new MyClass' constantly and want to avoid a call to malloc each time (but having to use 'new' constantly may be a sign of bad design also...). But to say the truth, even in speed-critical code I had to make, I never needed to do it: in those cases, the total number of objects existing at one time was generally bounded, so I could just allocate the max objects at startup and handle the free/used state of each object by a simple true/false flag embeded in each of them.
Now, how the STL containers handle their own memory consumption is a different matter, and we could speak about how it uses linked list, (RB) tree, etc. But as a user of the STL, you don't really need to know those details.

[:wumpus:]

Thanks for the wonderful answers everyone.

On the memory topic: What are the most common constructions for memory handling used in Ogre, Ode etc.. ie: is there a more often than not used technique (linked lists, octrees, hash tables, etc..), or is it just scattered in an organized, yet non-connected way?

Use STL (http://www.sgi.com/tech/stl) for all your container needs, don't *ever* code your own hash tables and balanced trees unless you know your implementation is better than all the others. (slim change given the algorithmic experience of the people writing STL implementations)

[alphabeta]

as wumpus said, the stl was written for performance, and you can safely trust in their experience.

Octree's are used for spatial organization (there is an octree scene manager for example), often used by physics engines. They don't organize memory so much as efficiently partition 3dimensional space (though memory can become an issue in spatial containers as well). Like stl containers, they have their costs and benefits. Unlike stl containers, you can feel free to write your own spatial organization systems, but you'll do well to look at some of the accepted algorithms (loose octrees for example).